Proposal: Introduce a new `init` subcommand to enhange developer experience for adding new packages (with ChatGPT)

With @developer-guy, we thought an idea to enhance overall developer productivity when adding a brand-new packages. Find the proposal below.

---

Abstract

Introduce a new init sub-command to significantly improve the developer experience for all the contributors by creating automated package templates for both Chainguard Image and Wolfi Package.

Motivation

Currently, creating a new package from scratch is time-consuming since developers have to find-out for information (license, version, descrption, etc.) of the packages from the upstream repositories. There could be an automated way to tackle this problem. We can save tons of hours!

Implementation

Option 1 (interactive)

After running wolfictl init, you can choose one of the following templates:

• melange: Suitable for a Wolfi package by creating melange.yaml.
• apko: Suitable for a Chainguard Image by creating apko.yaml.

End user should use arrow to move.

1. Use the GitHub API to fetch all the required information from the repository to use as default values
2. Ask the prompts: Name:, Description, License, etc. (with default values)
3. As soon as we gathered all the needs, ask a final [Y/n] question to initialize the package template.
4. Enlight the way of the developer by printing very descriptive logs. (directory it was created, what to do next, etc.)

1: If melange selected

1. Create a <NAME>.yaml with following template:
2. Optional: Fetch APKBUILD file by searhing https://git.alpinelinux.org/ (or https://search.nixos.org/packages to get propagatedBuildInputs) and call OpenAI API (by using ChatGPT) to read and convert the file content to melange corresponding (if possible)
3. Optional: If it's Go image, run Grype for the image and append go get commands to mitigate CVEs in runs pipeline
4. Include the package in packages.txt (at random line to prevent conflict)

package:
  name: NAME
  version: LAST VERSION
  epoch: 0
  description: GITHUB DESCRIPTION
  copyright:
    - license: GITHUB LICENSE

environment:
  contents:
    packages:
      - wolfi-base
      - busybox
      - ca-certificates-bundle
      - build-base

pipeline:
  - uses: fetch
    with:
      uri: UPSTREAM REPO/${{package.version}}.tar.gz
      expected-sha256: EXPECTED SHA
      expected-commit: EXPECTED COMMIT

  - runs: |
      # TODO

  - uses: strip

update:
  enabled: SET TRUE IF ACTIVELY MAINTAINED REPO (IF LAST COMMIT DATE < 1y)
  github:
    identifier: REPO/PROJECT
    use-tag: true
    tag-filter: "TAG"

2: If apko selected

1. Init a new package tree:

PACKAGE NAME
├──configs 
│  └──latest.apko.yaml 
├──image.yaml 
├──README.md 
└──tests 
   ├──01-runs.sh 

2. In the directory, init image.yaml and README.md the the following templates:

status: experimental
versions:
  - apko:
      config: configs/latest.apko.yaml
      extractTagsFrom:
        package: PACKAGE
      subvariants:
        - suffix: -dev
          options:
            - dev

5. To fill configs/latest.apko.yaml file, we can get the wolfi/os package corresponding if exist. (if doesn't we can error out: "Wolfi package is not exist. Create it first to initialize a new apko file):

contents:
  repositories:
    - https://packages.wolfi.dev/os
  keyring:
    - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
  packages:
    - ca-certificates-bundle
    - wolfi-baselayout
    - PACKAGE NAME

accounts:
  groups:
    - groupname: nonroot
      gid: 65532
  users:
    - username: nonroot
      uid: 65532
      gid: 65532
  run-as: 65532

entrypoint:
  command: /usr/bin/PACKAGE (or auto-detect)

archs:
- x86_64
- aarch64

annotations:
  "org.opencontainers.image.authors": "Chainguard Team https://www.chainguard.dev/"
  "org.opencontainers.image.url": https://edu.chainguard.dev/chainguard/chainguard-images/reference/PACKAGE/
  "org.opencontainers.image.source": https://github.com/chainguard-images/images/tree/main/images/PACKAGE

6. Search for Dockerfile in upstream repo to fill out entrypoint and metadata fields

7. Create a 02-helm.sh if possible. Use the ArtifactHub to search Helm package corresponding and in case we find something, append the Helm testing template: (this is a bit tricky since we have to parse the values.yaml to find image.repository and image.tag fields)

$ helm repo add PACKAGE_NAME REPO_ADDR
$ helm upgrade --install PACKAGE_NAME \
    REPO/PACKAGE \
    --set image.repository=cgr.dev/chainguard/PACKAGE \
    --set image.tag=latest-arm64

README: Like this, in the ## Using PACKAGE we can put the entire README here (or auto-find the Usage section if exist, or maybe custom template, or we can even use ChatGPT!)

IDEA: In the future iteration of this sub-command, we can include additional templates for each language (Go, Node, Python, etc.).

Option 2

Same with Option 1, but do not use prompts. Override with given flags instead.

• `wolfictl init melange [OPTIONS]
• `wolfictl init apko [OPTIONS]

Open Questions

1. Should these sub-command only work if active working directory is chainguard-images/images or wolfi/os?
2. Does it make sense in overall?
3. Would this CLI repo is right place for such a this feature? (Since the context of this CLI is mostly for Wolfi; what about monopod?)
4. Any ongoing work or proposal for this? (or maybe similar idea)

/cc @jdolitsky @patflynn @dlorenc

The issue names no files, tests, or entry points. Start by reviewing the existing wolfictl subcommands and package-generation flow, then resolve the open questions and choose a bounded melange or apko scope. Done should include agreed prompts or flags, generated templates, and defined checks for the external lookups and resulting files.