-
Notifications
You must be signed in to change notification settings - Fork 61
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ci] add infrastructure for automated releases/publish to npm (latest) #1056
Conversation
ec4148f
to
50a37b8
Compare
# - repo:status, repo_deployment, public_repo, read:org | ||
# See here for more details: | ||
# https://docs.github.com/en/actions/security-guides/automatic-token-authentication#using-the-github_token-in-a-workflow | ||
token: ${{ secrets.GH_COMMITTER_TOKEN }} |
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.
I added that secret/token
@@ -0,0 +1,8 @@ | |||
tag: v0.0.0 |
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.
I created and pushed that tag, on commit 412b849 - Trace viewer prototype application
(the second commit in this repo, right after "Initial commit"). This way, the first generated release notes will go back to the start of the repo's history (we can edit them after as needed)
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.
There is already a 0.1.0 release that was manually pushed to npm and a tag in the repo. Shouldn't you base the new release on the 0.1.0 tag instead?
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.
We could, but then the auto-generated release notes would start at v0.1.0. The plan is, after the next release, I will take the release notes and move those relevant to v0.1.0 into a manually-created GitHub release (from that tag). I did similar for time-line chart: https://github.com/eclipse-cdt-cloud/timeline-chart/releases
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.
timeline-chart: original release notes / GH release, that I manually massaged after release:
eclipse-cdt-cloud/timeline-chart#274 (comment)
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.
Right. Forgot about it. Makes sense.
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.
BTW, I'm not sure I was totally clear - the discussed tag (v0.0.0) will only affect the starting point for the auto-generated release notes, when we proceed with the first release, in another PR. This PR here will not result in a release, just setting the stage.
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.
thanks for clarifying
50a37b8
to
d68a2c6
Compare
Is it still a draft or ready for review? |
7378429
to
c613bb6
Compare
Yes, I think so. I will transition it out of "draft". |
Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
Signed-off-by: Marc Dumais <marc.dumais@ericsson.com>
c613bb6
to
7048c9e
Compare
I'm going to review it. It looks good so far. |
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.
Thanks for this contribution. It will make it easy to produce release.
Thanks for the review! |
This PR adds infrastructure to create GitHub releases (including auto-generated release notes) and publish
latest
npm packages, as part of the CI of this repository. See updated root README for instructions about how to trigger a release.Note: it's expected that the "GitHub release" job will fail at this point.