docs(README): clarify how tags: set version - #562
Conversation
Signed-off-by: Brendon Smith <bws@bws.bio>
If you read the Lines 794 to 810 in 318604b Just like the first sentence clarifies, When the docs refer to the first tag in the list to be selected, it is not referring to the unsorted tags: |
type=sha
type=raw,value=hello
type=raw,value=belloThe Your PR here would be removing this useful information. |
The GitHub Actions actions for Docker, such as docker/build-push-action, have some drawbacks: - The Docker actions may be confusing to use (docker/build-push-action#80, docker/metadata-action#561, docker/metadata-action#562). - The Docker actions may silently allow antipatterns. For example, when specifying annotation levels, Docker [documents](https://docs.docker.com/build/metadata/annotations/#specify-annotation-level) that "the build must produce the component that you specify, or else the build will fail." This means that building a single-platform image with `DOCKER_METADATA_ANNOTATIONS_LEVELS="index,manifest"` should fail (and does, with the Docker CLI), because single-platform builds can't apply index annotations. However, with the Docker actions, this error is silently allowed (for an example of an incorrect workflow that succeeds, see [br3ndonland/infrastructure-live](https://github.com/br3ndonland/infrastructure-live/blob/b57f978b781fb3a31d73854d9e4090f6f505c2f4/.github/workflows/ci.yml#L114-L122)). - Including Docker actions in GitHub Actions workflows necessitates version updates. That means more Dependabot or Renovate bot PRs that have to get reviewed and merged, or more manual updates if bots aren't used. - The maintainers aren't always attentive to community contributions (docker/metadata-action#587). Why wait months or years for maintainers to consider adding something to the actions when you can just do it directly with the Docker CLI right now? - Docker actions make it more difficult to align CI image builds with local development builds. Local development builds typically use CLI commands, but the actions are opaque TypeScript libraries. It would be simpler to replace the actions with CLI commands instead. The actions can be easily replaced: 1. docker/setup-buildx-action is unnecessary because Buildx is included on GitHub Actions runners by default. Its "builders" can be set up with `docker buildx create` commands. 2. docker/login-action can be replaced with `docker login` commands. 3. docker/metadata-action can be replaced by specifying metadata inputs as environment variables. 4. docker/build-push-action can be replaced with `docker buildx build` commands. As a starting point, the commands can be based on outputs of previous docker/build-push-action GitHub Actions workflow jobs. 5. crazy-max/ghaction-github-runtime (for setting up the "GHA" GitHub Actions cache) can be replaced with a simple Node.js action that exports environment variables for later shell steps. This commit will implement a replacement for the above five actions with a script and local Node.js action. The README will document how to use the replacement script and action.
Description
Closes #561
The README says,
That doesn't seem to be correct.
Example run here.
Workflow file had
type=shalisted first:But then the action output was
org.opencontainers.image.version=main.Changes
This PR will update the wording in the README to clarify that
versionis determined by the highest-priority tag in thetags:input list, regardless of the order of the items in the input.