Releases (and versioning)

[jeffmendoza]

Allstar is most easily used by installing the app However, it is also intended to be able to be run separately if desired, as described here.

Those wanting to run Allstar themselves can easily build it the same way we do (ko publish ./cmd/allstar), but some may want to consume a release. Therefore. I propose we start building and publishing releases. The process will be documented and checked in, such as:

Stage: WIP, Draft, Proposed

Release process

The workflow is laid out in .github/workflows/release.yaml. This GitHub Action workflow is triggered by the creation of a tag. It builds Allstar using ko. This is then pushed to GitHub's container registry with the name allstar and the tag vX.Y, where X is the major version, and Y is the minor version. The container will be signed with sigstore/cosign. Also, a GitHub release is created.

Cadence

The workflow is manually triggered monthly by the maintainers, in sync with the monthly allstar-announce group email. At the same time, the whats-new.md is updated for what was sent in the email, and an empty section is created for next month's email.

Version

Allstar is not a library and will not use semver, it's version should convey some sort of meaning to it's consumers (app operators), therefore the major version should be bumped when:

• Any functionality change is included (see functionality change proposal/process).
• Any new policies are included.
• Any major features are added (maintainer discretion).

Releases without any of the above will only have a minor version bump.

[jeffmendoza]

Exmaple workflow to use: https://github.com/haydentherapper/hello-ko/blob/main/.github/workflows/build.yaml

[justaugustus]

While I haven't had an opportunity to use it (yet), the goreleaser GitHub Action is worth a look: https://github.com/goreleaser/goreleaser-action

(You can sign with cosign: https://goreleaser.com/customization/sign/#with-cosign)

[jeffmendoza]

Moved to draft, will propose with a PR of this process soon.

[justaugustus]

cc: @ossf/scorecard-maintainers

[testworksau]

We'd welcome this proposal; we are planning on self-hosting as we need our repos to have some form of protections applied to them as quickly as possible once they have been created (we're aware of the thoughts about converting the app to work from webhooks, which would also be great).

Whilst we can - as you say - build it ourselves, it would be good to remove a little friction, complexity, and time we would have to spend on this task.