-
Notifications
You must be signed in to change notification settings - Fork 1
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
Publish artifacts to Maven Central #6
base: main
Are you sure you want to change the base?
Conversation
@wborn I had to delete the secrets I added specifically the https://github.com/openremote/openremote/actions/runs/8662288322/job/23753942442?pr=1289 This will need investigating and likely related to the newline |
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.
See code comments
id 'signing' | ||
} | ||
|
||
version = hasProperty("appVersion") ? appVersion : "1.2.0-SNAPSHOT" |
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.
Not sure we want a baked in version which would quickly be out of sync. Maybe 0.0.0
if nothing is supplied would be better?
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.
The issue is that snapshot builds need a proper version. That way you can keep track of which snapshot version of the ORLib you have been testing with. Especially when producing snapshot versions on multiple branches e.g. 1.2.1-SNAPSHOT for a hotfix and 1.3.0-SNAPSHOT for the next bigger release.
Maybe it is best to add these versions to gradle.properties
instead and update them before/after release? Such updates can then be done by the GHA release workflow.
That's similar to how it's normally done on Maven projects. The best practice is that release builds are reproducible. So in that case you don't want to provide version numbers as environment variables but have them as part of the files in the repo.
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 can understand having them in the codebase for reproducability but the downside is remembering to change them but an automated process will mitigate this risk.
Obviously we should minimise in how many places such values need to be set and indeed inheriting from gradle.properties
makes sense, I believe this is already the case for the main openremote repo.
version = hasProperty("orlibVersion") ? orlibVersion : "1.2.0-SNAPSHOT" | ||
|
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.
Same comment here about version
0f0e646
to
cebafcf
Compare
With these changes GHA will also check if PRs build successfully.
Snapshot artifacts are published to Maven Central (https://s01.oss.sonatype.org/content/repositories/snapshots/io/openremote/) on pushes or workflow dispatches on the main branch.
When a release is created the workflow will publish the artifacts to a staging repository on Maven Central (https://s01.oss.sonatype.org/#stagingRepositories).