ci: autogenerate release #269
Conversation
There was a problem hiding this comment.
Did you also want to copy what I do in https://github.com/DevelopingSpace/starchart/blob/main/.github/workflows/ci.yaml#L311-L353 and have it also build and push a production image? You'd probably use type=semver for this, and also bump latest and main
| @@ -30,3 +27,42 @@ jobs: | |||
| # generate release name with the tag name that was just pushed | |||
| automatic_release_tag: ${{ steps.vars.outputs.tag }} | |||
| prerelease: false | |||
| Docker-Build: | |||
| # We'll only build and push when landing on main, not for PRs | |||
| if: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }} | |||
There was a problem hiding this comment.
I don't think we need this, since we'll never run this in response to a PR, right (only on tag)?
| flavor: latest=true | ||
| tags: | | ||
| type=semver,value=${{ steps.vars.outputs.tag }} | ||
| - name: Log in to the GitHub Container Registry |
There was a problem hiding this comment.
Blank line in between all steps, or none, but be consistent.
| permissions: | ||
| actions: write | ||
| contents: write | ||
| pull-requests: write |
There was a problem hiding this comment.
Can you educate me on this. Why are these last 2 required?
There was a problem hiding this comment.
I still need to mess around with those permissions. The github action to generate a tag needs some permissions to save the tag in the repo.
There was a problem hiding this comment.
Would we not push the tag ourselves? What is the workflow you imagine?
There was a problem hiding this comment.
Sorry, the gh action is used to generate the release when a tag is pushed. With default permissions given in a workflow, I get this error, that it doesnt have enough permissions to publish a new release
https://github.com/shawnyu5/starchart/actions/runs/4249711991/jobs/7390117298
There was a problem hiding this comment.
That error makes it seem like it wants to create a new tag, which seems odd if we push our own.
There was a problem hiding this comment.
I think its trying to generate the release. There seems to be a distinction between "release tags" and "git tags"?
Im not sure If I fully understand this yet tbh...
There was a problem hiding this comment.
I think you're right, and this is something I didn't fully understand. I found this helpful:
9.6.1
Tags and releases—the differences
Well a tag is just a unique symbolic name attached to a particular commit point. Git supports two types of tag (§ 6.3.4) a lightweight tag (without a message) and an annotated tag (with a message). In Brackets we only have lightweight tags.GitHub can display both. In Figure 9.82 above, the tags are all lightweight, I can tell this because it tells me there is no release notes for any of the tags, this release note is what Git refers to as the tag message attached to the annotated tag. If we added a release note it would become an annotated tag.
A release on the other hand is a GitHub object, it is still attached to a particular commit point, but this time it allows us to specify that a particular commit has a particular release status.
GitHub converts all our tags to releases when we push them up from the local repository and that is why they are listed as both releases and tags.
So GitHub does want our manually created tag, and will use it to create a new GitHub Release (tag) object, which is why it wants elevated privileges.
There was a problem hiding this comment.
ah that makes sense. Tho I don't think it needs all those permissions there, I just put them there for now so I can move on to test the rest of the action. I should remove the ones the action does not need.
|
@shawnyu5, just checking in to see if you are still working on this PR. |
|
Closing in favour of #466 |
Closes #249
A GitHub actions to auto-generate a release tag upon the push of a new tag
New release tags should be generated using
npm version major | minor | patch, and hence should adhere to the format ofv*(v0.1.2). This action will only work with tags prepended withvThis CI job should not enforce all CI should pass before creating a new release. That decision should be on the person creating the release to decide.