-
Notifications
You must be signed in to change notification settings - Fork 100
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
feat: 1588 publish to maven central #1596
Conversation
... into env vars.
This contribution does not follow the conventions set by the Google Java style guide. Please run the following command line at the root of the project to fix formatting errors: |
✅ Rule acceptance tests passed. |
… main. The java format verifier does not like it.
This contribution does not follow the conventions set by the Google Java style guide. Please run the following command line at the root of the project to fix formatting errors: |
.github/workflows/release_jars.yml
Outdated
on: | ||
release: | ||
types: [ prereleased, released ] | ||
workflow_dispatch: |
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.
It might be more generic to trigger the action by listening to tag pushes so that any new tag will be published.
Example:
on:
push:
tags:
- '*'
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.
Sure. But it should be restricted to tags that have the proper syntax (e.g. v4.2.1), If not the axion-release plugin will not work. I initially was using an uppercase V at the beginning of the version, and it did not work! It came with some headaches.
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.
Did not put tag as a trigger in the end since the other part of publish_assets.yml needs a release trigger.
.github/workflows/release_jars.yml
Outdated
# At this point it should manually be closed, which will trigger acceptance tests for maven central (but not transfer yet) | ||
# Once closed, thew repo is available for testing. | ||
# After testing, it can be manually promoted on the sonatype site, which will then publish to maven central. | ||
name: Upload Release Jars to Sonatype |
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.
What do you think if we add the jobs implemented here to
name: Upload Release Assets |
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.
So you want to combine the two actions?
Or have one trigger the other
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.
Combining the two actions seems to be a reasonable solution.
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.
Combining is possible, but having a tag push as a trigger instead of a release event will not work since the action uploads to a release and needs the release event to obtain the release url.
To keep them combined we could trigger on both the release event and the tag push event, but select the steps that are run on each event, ie dont tun the upload to release if it's not a release event.
Or we could separate them and each have their own trigger.
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 see your point. My bad, I was looking at the default example from upload-release-asset
action and the implementation is the other way around. They create a release as part of the tag push: https://github.com/actions/upload-release-asset#example-workflow---upload-a-release-asset.
To conclude, let's leave the pre-release and release triggers.
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.
Still kept them combined but added a workflow_dispatched trigger that is used only by the sonatype upload.
✅ Rule acceptance tests passed. |
… push a tag instead of release or prerelease.
This contribution does not follow the conventions set by the Google Java style guide. Please run the following command line at the root of the project to fix formatting errors: |
✅ Rule acceptance tests passed. |
…spatch (manual) but limited it to the Sonatype upload.
This contribution does not follow the conventions set by the Google Java style guide. Please run the following command line at the root of the project to fix formatting errors: |
This contribution does not follow the conventions set by the Google Java style guide. Please run the following command line at the root of the project to fix formatting errors: |
This contribution does not follow the conventions set by the Google Java style guide. Please run the following command line at the root of the project to fix formatting errors: |
✅ Rule acceptance tests passed. |
This looks good to me. As a last ask, can you update the release documentation, adding the steps to publish to maven? Thanks! |
✅ Rule acceptance tests passed. |
You can now use Maven Central as repository for released versions of GTFS-validator artifacts. |
Summary:
closes #1588
Modified the build.gradle of the modules to upload (main, core and model) to add signing and publishing.
Added a Github action to publish the released artifact.
Expected behavior:
To publish, you need to have a git tag directly in the commit, with semantic versioning format.
The GH action can be triggered by hand or for a prerelease or release.
If successful, there will be a new staging repo in https://s01.oss.sonatype.org/index.html#stagingRepositories containing the artefacts (e.g. https://s01.oss.sonatype.org/content/repositories/orgmobilitydata-1029/. This repo will likely be deleted by the time you read this, but it should be similar)
The artefacts should be signed (look for .sha1, .sha256 etc)
To test the deployment, you have to manually close the repo on sonatype. This will trigger acceptance tests for maven (artefacts are signed, etc).
If successful the staging repo will be available to use for testing. You will need to add a repository with the URL mentioned above (or similar) to your pom.xml or build.gradle.
Once the testing is done, the repo can be manually promoted to maven central.
Please make sure these boxes are checked before submitting your pull request - thanks!
gradle test
to make sure you didn't break anything