Add release workflow #168
Add release workflow #168
Conversation
Pull Request Test Coverage Report for Build #518Details
💛 - Coveralls |
|
Fixes #160 Adds the release workflow for automated releases using tags like For simplicity, I copied the build parts into the release.yml workflow even though they are recomputing some artifacts from the tests.yml workflow. Alternately, I would need to add the cc @nrabinowitz |
.github/workflows/release.yml
Outdated
| # - master | ||
|
|
||
| jobs: | ||
| # tests and tests-no-docker are from tests.yml and build the actual native libraries that will be used in the release. |
There was a problem hiding this comment.
Does that mean that these two also need to have the exact same name or it won't line up correctly? Because having a job called tests in the release yaml file feels kinda weird.
There was a problem hiding this comment.
I could rename them to be clearer that they are just here for building the artifacts, but keeping the same names makes it easier to copy changes back and forth.
edit: I have updated the names to be clearer what they are actually doing
.github/workflows/release.yml
Outdated
| # For testing: | ||
| # pull_request: | ||
| # branches: | ||
| # - master |
There was a problem hiding this comment.
Delete?
| # For testing: | |
| # pull_request: | |
| # branches: | |
| # - master |
There was a problem hiding this comment.
I find this helpful to have on hand for testing the workflow in a PR, but probably don't want to leave it in after initial tests.
| matrix: | ||
| os: [ubuntu-latest] | ||
| java-distribution: [adopt] | ||
| java-version: [8] |
There was a problem hiding this comment.
8 is EOL, right? Should we move this higher?
There was a problem hiding this comment.
I've seen different things about Java 8. It seems Oracle has very long term support for it, but it does seem practically EOL. I'm not sure how much the open source ecosystem is still supporting it as I haven't done as much Java work recently.
My plan was to leave the baseline at Java 8 for now (since that is what we previously built) and then in a follow up PR re-enable some code quality tools and bump the baseline to a newer LTS release.
| with: | ||
| tag_name: "v${{ env.RELEASE_VERSION }}" | ||
| release_name: "${{ env.RELEASE_VERSION }}" | ||
| body_path: CHANGELOG.md # assumes changelog contains latest release notes at top |
There was a problem hiding this comment.
Will this include the entire changelog per release? Or just the latest release?
There was a problem hiding this comment.
Based on the repo https://github.com/softprops/action-gh-release I think it is set up to take the first markdown section, the generated release should be very easy to manually modify after the fact if the detected changelog is not right.
|
Has this had an end-to-end test on a dummy repo? Any open questions on functional correctness? If so, is the plan to fix foward upon an issue? Would be great to have the verification documented in PR description. |
No, I have not had an opportunity to test this on a dummy repo. My plan was to fix forward as this repo has a relatively unique and complicated build process. If desired I could set up a new artifact on Maven Central and demonstrate this script is capable of pushing that first? |
|
I was able to get "published" status using my own namespace publishing in Sonatype Central Repository. (It doesn't show up on Maven Central Search, I think this is either a delay in showing up there or because I used staging URLs, in the second case that part was unique to my repo and in this PR I used the provided URLs. Since it is not my account I cannot validate that part of the process :) ) 
The only outstanding issue is that the release notes generated get the entire contents of CHANGELOG, this is easy to manually fix after release. I will try to fix that but I don't think that is blocking. |
|
It appears my copy published correctly: https://repo1.maven.org/maven2/io/github/isaacbrodsky/h3/ |
|
I'll update the changelog date for 4.3.0, merge, and try releasing in the next few days. |
| @@ -2,6 +2,10 @@ | |||
|
|
|||
| The H3-Java library is published to Maven Central via OSSRH. | |||
|
|
|||
| Before releasing, make sure the version of the project is in the form `1.2.3-SNAPSHOT` where `1.2.3` is the version you wish to release. The release is triggered via GitHub Actions, when a tag of the form `v1.2.3` is pushed. (Workflow dispatch can be used but is not tested.) | |||
There was a problem hiding this comment.
Should this be:
when a tag of the form `1.2.3-SNAPSHOT` is pushedThere was a problem hiding this comment.
No, the tag should be the release version with v prefixed. Cf. successful run here: https://github.com/isaacbrodsky/h3-java/actions/runs/15884738203
No description provided.