Modify action to build and consume container #124
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,20 @@ | ||
| # Definition of the github action | ||
| # as per https://docs.github.com/en/actions/creating-actions/creating-a-docker-container-action | ||
|
|
||
| name: 'laminas/automatic-releases' | ||
| description: 'Automates automatic releases for semver-compliant repositories' | ||
|
|
||
| inputs: | ||
| command-name: | ||
| description: | | ||
| Command to execute: one of | ||
| * `laminas:automatic-releases:release` | ||
| * `laminas:automatic-releases:create-merge-up-pull-request` | ||
| * `laminas:automatic-releases:switch-default-branch-to-next-minor` | ||
| required: true | ||
|
|
||
| runs: | ||
| using: 'docker' | ||
| image: '../../../Dockerfile' | ||
| args: | ||
| - ${{ inputs.command-name }} | ||
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,39 @@ | ||||||
| name: Build and push containers | ||||||
|
|
||||||
| on: | ||||||
| release: | ||||||
| types: [published] | ||||||
|
|
||||||
| jobs: | ||||||
| release-container: | ||||||
| runs-on: ubuntu-latest | ||||||
| steps: | ||||||
| - name: Compile tag list | ||||||
|
There was a problem hiding this comment. you could use https://github.com/crazy-max/ghaction-docker-meta here There was a problem hiding this comment. True - but this is fast and doesn't require any additional overhead as it's using tooling already in the environment. Thanks for the link, though - I'd not seen that one! |
||||||
| id: tags | ||||||
| run: | | ||||||
| TAG=${GITHUB_REF/refs\/tags\//} | ||||||
|
There was a problem hiding this comment.
Suggested change
I'm sure I've already suggested this elsewhere. |
||||||
| PREFIX=ghcr.io/laminas/automatic-releases | ||||||
| MAJOR="${PREFIX}:$(echo ${TAG} | cut -d. -f1)" | ||||||
| MINOR="${MAJOR}.$(echo ${TAG} | cut -d. -f2)" | ||||||
| PATCH="${PREFIX}:${TAG}" | ||||||
| echo "::set-output name=tags::[\"${MAJOR}\",\"${MINOR}\",\"${PATCH}\"]" | ||||||
| - name: Checkout | ||||||
| uses: actions/checkout@v2 | ||||||
|
There was a problem hiding this comment. Not super-important, but some spacing (blank lines around blocks) would go a long way with improving readability |
||||||
| - name: Setup QEMU | ||||||
| uses: docker/setup-qemu-action@v1 | ||||||
| - name: Setup Docker Buildx | ||||||
| uses: docker/setup-buildx-action@v1 | ||||||
| - name: Login to GitHub Container Registry | ||||||
| uses: docker/login-action@v1 | ||||||
| with: | ||||||
| registry: ghcr.io | ||||||
| username: ${{ secrets.CONTAINER_USERNAME }} | ||||||
|
There was a problem hiding this comment. These secrets should be prefixed, to make it clear they are local to our build There was a problem hiding this comment. Done; used |
||||||
| password: ${{ secrets.CONTAINER_PAT }} | ||||||
| - name: Build and push | ||||||
| uses: docker/build-push-action@v2 | ||||||
| with: | ||||||
| context: . | ||||||
| file: ./Dockerfile | ||||||
| platforms: linux/amd64 | ||||||
| push: true | ||||||
| tags: ${{ join(fromJSON(steps.tags.outputs.tags), ",") }} | ||||||
|
There was a problem hiding this comment. So we push each image as 3 tags? Ok for me, hard to read/follow if not versed in github actions (requires comments around it) There was a problem hiding this comment. Yes - actual release version, minor release version, major release version. Rationale is that if we change something in a new minor release that causes issues for somebody, they can pin to the previous minor. Alternately, they can pin to a specific "known good" release. (There are existing actions for creating tags that do the same; I chose to do it using standard *nix tooling, as it introduces zero additional overhead.) |
||||||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I discovered is that while the image is in a directory relative to this one, the actual build happens relative to
$GITHUB_WORKSPACE, so everything works correctly. By doing this, we get the benefits of whatever changes we've made for this release... when creating the release.