CI: create release workflow #45
Conversation
Coverage report
This PR does not seem to contain any modification to coverable code. |
lalver1
force-pushed
the
ci/release-workflow
branch
from
e57be64 to
d314ea4
Compare
.github/lighthouserc.json
Outdated
| "ci": { | ||
| "numberOfRuns": 3, | ||
| "settings": { | ||
| "preset": "mobile" |
There was a problem hiding this comment.
I like that you added a lighthouse config + CI test 👍
But I don't think we need to worry about mobile as much for this website. It is decidedly not mobile-first 😅
There was a problem hiding this comment.
Ah that's true! I'll change it to "desktop" since that's what we actually want to test.
.github/workflows/deploy.yml
Outdated
| # pre-release tag | ||
| - "202[3-9].[0-9][0-9].[0-9]+-rc[0-9]+" | ||
| # release tags | ||
| - "202[3-9].[0-9][0-9].[0-9]+" |
There was a problem hiding this comment.
Nitpick but we could start these in 2024, we won't be making a 2023 release 😁
| pipdeptree >> pems/static/requirements.txt | ||
| - name: Write commit SHA to file | ||
| run: echo "${{ github.sha }}" >> pems/static/sha.txt |
There was a problem hiding this comment.
I'd also like to write the tag to a file like pems/static/version.txt -- can we do that here?
There was a problem hiding this comment.
I think so, looks like github.ref_name will give us the tag (shortname). So, for example, we could get 2024.12.1 in version.txt
.github/workflows/deploy.yml
Outdated
| context: . | ||
| file: appcontainer/Dockerfile | ||
| push: true | ||
| tags: ghcr.io/${{ github.repository }}:${{ github.sha }} |
There was a problem hiding this comment.
Can we try and tag the Docker image with the git tag as well?
There was a problem hiding this comment.
Yep, since it looks like github.ref_name is what we need, would this tag format (sha-version) work for us?
tags: ghcr.io/${{ github.repository }}:${{ github.sha }}-${{ github.ref_name }}
There was a problem hiding this comment.
I was actually suggesting the git tag in addition to the SHA (i.e. keeping them distinct). I think you can do:
tags: |
ghcr.io/${{ github.repository }}:${{ github.ref_name }}
ghcr.io/${{ github.repository }}:${{ github.sha }}There was a problem hiding this comment.
Check out these docs referencing the docker/metadata-action -- that seems useful?
| - name: Run Lighthouse tests for a11y | ||
| uses: treosh/[email protected] | ||
| with: | ||
| urls: http://localhost:8000 |
There was a problem hiding this comment.
Glad you saw the issue with /help 😁
The other issue is, it isn't certain that 8000 will be the port on localhost.
We may need to introduce an environment variable like DJANGO_LOCAL_PORT, and use that in the compose service (with a default value) to ensure we have a known port binding.
Related, I added DJANGO_DEBUG=true as default in the environment file, but maybe this shouldn't be in there at all. We want the lighthouse tests to run on the non-debug / real app.
There was a problem hiding this comment.
Yep, I had overlooked the /help url 😅
Thanks, I modified ports in the compose file (following the way we do it in Benefits) so that we use DJANGO_LOCAL_PORT on localhost if it's available, and if it's not, it defaults to 8000.
Right, I removed DJANGO_DEBUG=true from the environment file. I think this shouldn't be a problems since (at least until now) we only use DJANGO_DEBUG when starting a debugger (and we already set it in the debugger configuration) and in settings.py (and it gets a default value of False so that's ok). If the user wants to set it to True, they can override it in their .env file.
- pushing a calver formatted tag kicks off a release - run tests, build app container image, push to GHCR - for a release tag, make a GitHub release
so that lighthouse tests run on the non-debug / real app
lalver1
force-pushed
the
ci/release-workflow
branch
from
d314ea4 to
79e1ec3
Compare
Closes #11
This release workflow is triggered by pushing a calver formatted tag. The workflow: