Add publish job to ci workflow #208
Conversation
| publish: | ||
| runs-on: ubuntu-latest | ||
| needs: test | ||
| if: github.event_name == 'push' && github.ref == 'refs/heads/master' |
There was a problem hiding this comment.
Does this mean every push to master updates Docker? Shouldn't that be limited to releases of the package (i.e., to npm)?
There was a problem hiding this comment.
So I went with each push to master so that if someone wants to use what is in the master branch, it's immediately available and it isn't put on the user to build this from scratch. Once this is in place, we could then add a release workflow that would also create a tagged version of the image.
There was a problem hiding this comment.
I think I'd prefer doing releases first - or at least together. I'd also prefer a trigger, I think - most of the commits are Dependabot and there's not much point publishing a new release because a devDependency updated.
There was a problem hiding this comment.
That makes sense. I can make some changes to make it happen that way and then if we see that there is a need to make more frequent releases we can always add it back later.
| uses: docker/login-action@v1.10.0 | ||
| with: | ||
| registry: ${{ env.REGISTRY }} | ||
| username: ${{ secrets.REGISTRY_USERNAME }} |
There was a problem hiding this comment.
Who provides these secrets and maintains them?
There was a problem hiding this comment.
This would be on the repo owner(s). They just need to be created and maintained by creating secrets in the repo settings.
There was a problem hiding this comment.
I do not (currently) have Docker credentials.
There was a problem hiding this comment.
Gotcha. At least from what I was able to gather, I don't think there is an existing docker/quay/etc. repository for this. So it would be as simple as just creating one? But I may be wrong here.
There was a problem hiding this comment.
@DavidAnson I was actually looking at this and this could be as simple as just using the github container registry. Since everything can be easily integrated with github actions, there won't be any external credentials or repositories to deal with. Does this sound like a better approach?
There was a problem hiding this comment.
Maybe? I'm actually looking at Docker for CLI2 due to another PR and learning more as part of that. I think I like how that approach is coming together, but your solution for authentication may be better for this project. I don't mind owning the publish process for a tool I own (CLI2), but am reluctant for one I do not (this CLI).
Follow along here if curious: DavidAnson/markdownlint-cli2#28
.github/workflows/ci.yml
Outdated
| @@ -36,3 +36,35 @@ jobs: | |||
|
|
|||
| - name: Run tests | |||
| run: npm test | |||
|
|
|||
| publish: | |||
There was a problem hiding this comment.
Or can this be in its own file?
There was a problem hiding this comment.
It's better to have this in the same file and just use various conditionals to trigger this so that we make sure we're only building this when other CI passes.
There was a problem hiding this comment.
Fixed the name as requested.
|
@tylerauerbeck, after some Googling, it seems the following two pages outline how to use the GitHub container registry from an action:
I may need to tweak a permission on the repo, but otherwise this seems to enable the login, build, and publish of a container without explicitly managing or sharing accounts and passwords. |
|
Any update on this? I'd love to use a docker image published from this repo. |
|
If no one beats me to it, I will have a look when I get to this project in my rotation. Probably a couple of weeks or so. |
|
@DavidAnson Sorry, this one fell off my radar. I'm happy to update this to publish to GHCR if you'll have some time for review. |
|
It's a deal! :) |
…n a tag is pushed (refs #208).
…n a tag is pushed (refs #208).
|
As of |
This PR adds a job to the ci workflow that builds an image using the latest build to a specified container registry and tags it with the latest tag. This job only runs when the ci job is successful and when a push occurs to the master branch (ensuring that all tests have passed).
The only requirements this has is that the container registry of choice is specified in the environment vars for the job and that two secrets are created in the repository (
REGISTRY_USERNAMEandREGISTRY_PASSWORD).You can see the output of this workflow here (where I had specified my own repo/credentials):
https://quay.io/repository/tauerbec/markdownlint-cli?tab=tags
https://github.com/tylerauerbeck/markdownlint-cli/runs/3114894787?check_suite_focus=true
This also fixes a small issue I had encountered with the
.dockerignorefile and bumps the Dockerfile to build fromnode:14-alpineFixes #205