#2503 push SNAPSHOT Maven artifacts to github Packages #2525

icrc-fdeniger · 2024-04-23T09:49:31Z

Fixes #2503

Description
Publish Maven artifacts in GitHub Packages

Type
Feature

Checklist

Tests done https://github.com/icrc-fdeniger/android-fhir
Maven packages are deployed here: https://github.com/icrc-fdeniger?tab=packages&repo_name=android-fhir ( will be done on google/android-fhir)
maven-repository.zip artifact is deployed as usual ( not sure about the usage of this artifact but not changes).
See https://github.com/icrc-fdeniger/android-fhir/actions/runs/8798380904/job/24145256498 for a full deployment

Versions

When the maven artifacts are deployed in GitHub Packages the SNAPSHOT prefix is used to follow Maven coventions.
When the maven artifacts are deployed in official maven repositories, the SNAPSHOT prefix is not used ( as it's done actually as far as I can understand)
In the PR, the artifact versions has been updated to next expected release version:
- for instance, commonmodule will be automatically deployed with the version 0.1.0-alpha06-SNAPSHOT in GitHub Packages and with 0.1.0-alpha06 in the next release.

Suggestion/question
why not removeing beta/alpha as versions like 0.X.Y are considered as development version ?

Current Version	Used in this PR	Proposition
common:0.1.0-alpha05	common:0.1.0-alpha06	common:0.1.1
engine:1.0.0	engine:1.0.1	engine:1.0.1
data-capture:1.1.0	data-capture:1.1.1	data-capture:1.1.1
workflow:0.1.0-alpha04	workflow:0.1.0-alpha05	workflow:0.1.1
ontrib-barcode:0.1.0-beta3	ontrib-barcode:0.1.0-beta4	ontrib-barcode:0.1.1
contrib-locationwidget:0.1.0-alpha01	contrib-locationwidget:0.1.0-alpha02	contrib-locationwidget:0.1.1
knowledge:0.1.0-alpha03	knowledge:0.1.0-alpha04	knowledge:0.1.1

if a dev Team wants to use an alpha/beta version it can use a dependency to a SNAPSHOT version ( the "unstable version created from the last build").
it's also possible to specify the artifact of a build with by example: engine-1.0.1-20240423.083712-3

vorburger

LGTM, based on an initial quick glance... but a "core team" member and not just me should probably also rewiew this PR.

icrc-fdeniger · 2024-05-06T07:24:22Z

Hello @santosh-pingle, @ktarasenko
please tell me if this PR need to be modified. I understand that the version updates are the "tricky" part and will be happy to modify this. My point was to update them to the next version as GitHub Actions should produce SNAPSHOT of next versions.

Thanks

vorburger · 2024-05-06T13:16:10Z

@icrc-fdeniger FYI the artifact version number changes introduced here will cause build failures once you rebase this after #2533 is merged. The required fix (after you have rebased it, not right now) is as simple as changing those version numbers also in the (new, TBD) docs/use/api.md file; hopefully that's trivial. Please do shout if unclear!

@MJ1998 @santosh-pingle @ktarasenko merge this only after #2533.

…deploy-repo

icrc-fdeniger · 2024-05-09T20:38:54Z

@vorburger @santosh-pingle @ktarasenko should be ok now

vorburger · 2024-05-10T14:38:09Z

@vorburger @santosh-pingle @ktarasenko should be ok now

LGTM! I say let's merge this... @santosh-pingle @ktarasenko @MJ1998 no objects, right?

MJ1998

LGTM but requesting @aditya-07 to approve.

buildSrc/src/main/kotlin/Releases.kt

MJ1998 · 2024-05-13T16:09:28Z

Thanks for this PR @icrc-fdeniger. LGTM.

About the version proposal we would wanna keep the alpha/beta naming conventions. Reason - Using alpha and beta suffixes aligns with established conventions in semantic versioning and open-source software development. So we would like to stick with it.

buildSrc/src/main/kotlin/Releases.kt

MJ1998

LGTM

buildSrc/src/main/kotlin/Releases.kt

…deploy-repo # Conflicts: # buildSrc/src/main/kotlin/Releases.kt

icrc-fdeniger · 2024-05-31T16:30:12Z

@santosh-pingle any news on that PR ?

jingtang10

Thansk @icrc-fdeniger for this contribution! 🙏

For some background on the maven-repository.zip artifact, see this PR from @yigit:
#249. We also have some documentation and I just realised it's a bit messed up after our recent documentation migration to this page: https://google.github.io/android-fhir/contrib but for your information the original text is this:

Use unreleased GitHub build (for development/testing only)

Each GitHub build of the project also contains a maven repository. You can access unreleased features by downloading it and including it in your project. To acquire the maven repository, go the the actions page, and click on the build you want. In the build artifacts dropdown, you will find a maven-repository.zip file. After downloading and extracting it to a local folder, you can add it to your gradle setup via:
repositories {
  maven {
    url "file:///<path to the unzipped folder>"
  }
}
These artifacts are versioned as a combination of the current version + buildid (e.g. 0.1.0-alpha01-build_123). You can find the version in the zip file by checking the contents of it and update your build file to match that version.

OK, now onto github packages - with this change, do we always overwrite the SNAPSHOT? so if I have a PR in development, and I push a new commit it will overwrite the github packages?

Another thing we might need to be careful about is just any incurred cost - https://github.com/features/packages#pricing. With our repo under google organisation I'm hoping that we'll be covered by the google organisation quota/allowance. But I will investigate.

jingtang10 · 2024-06-05T16:44:24Z

docs/use/api.md

+* [Engine](api/engine/1.0.1/index.html)
+* [Data Capture](api/data-capture/1.1.1/index.html)
+* [Workflow](api/workflow/0.1.0-alpha05/index.html)
+* [Knowledge](api/knowledge/0.1.0-alpha04/index.html)


this would break our existing doc. please revert this change.

jingtang10 · 2024-06-05T16:48:06Z

buildSrc/src/main/kotlin/Releases.kt

It seems to me the PR is doing 2 things: set up the snapshot artifacts on github and updating the version numbers. In the spirit of making things independent, can we revert the version number change?

I think we need to do both in this PR. Version update indicates the future version to be released .. the snapshot of which is released in GitHub package.

If we don't update the version, the snapshot will be pushed with version that has already been released..

@jingtang10 all done.
But I can revert again :) As @MJ1998 mentionned the point is to push a SNAPSHOT of the next release to help developper from other team to use the last version without having to download zip file and doing temporary changes in their local installation.

I think we need to do both in this PR. Version update indicates the future version to be released .. the snapshot of which is released in GitHub package.

If we don't update the version, the snapshot will be pushed with version that has already been released..

yeah i see your point - but we also don't necessarily determine version increments before an actual release - for example a breaking change might need to be introduced and we might need to actually bump up the major version. or maybe an urgent minior fix needs to go in immediately and we need to make a small version increment. this process would enforce us to know for which future version we're publishing the snapshots :/

i guess really - we're publishing snapshots for HEAD...

The way I have seen this conundrum resolved traditionally (in other Java projects using Maven version numbers) is simply that you "avoid" the "problem is that sometimes we don't know what the next version is"; by using https://semver.org numbering, and determining the version number "early". For example, if the last FHIR Engine that was released was v1.0.0, you should decide "now" (not when you release) if what's currently coming together on the master branch is going be the (future) v1.1.0, not v1.1.1. Therefore, the version number in Gradle would be set to 1.1.0-SNAPSHOT. When you release, you drop the SNAPSHOT and create a 1.1.0 release - and then immediately increment to 1.2.0-SNAPSHOT. When an urgent minior fix needs to go in immediately, then you git branch that off from the 1.1.0 revision and change the version to 1.1.1 (-SNAPSHOT, if more changes are possibly anticipated on such a maintenance branch; else never mind), on the branch (only). I hope this helps?

…deploy-repo

MJ1998 · 2024-06-06T07:40:38Z

OK, now onto github packages - with this change, do we always overwrite the SNAPSHOT? so if I have a PR in development, and I push a new commit it will overwrite the github packages?

Yes it will overwrite.

Another thing we might need to be careful about is just any incurred cost - https://github.com/features/packages#pricing. With our repo under google organisation I'm hoping that we'll be covered by the google organisation quota/allowance. But I will investigate.

I doubt if there will be a problem but we will beinformed by Google in case the quota reaches limit..

icrc-fdeniger · 2024-06-06T08:06:48Z

Thansk @icrc-fdeniger for this contribution! 🙏

For some background on the maven-repository.zip artifact, see this PR from @yigit: #249. We also have some documentation and I just realised it's a bit messed up after our recent documentation migration to this page: google.github.io/android-fhir/contrib but for your information the original text is this:
Use unreleased GitHub build (for development/testing only)
Each GitHub build of the project also contains a maven repository. You can access unreleased features by downloading it and including it in your project. To acquire the maven repository, go the the actions page, and click on the build you want. In the build artifacts dropdown, you will find a maven-repository.zip file. After downloading and extracting it to a local folder, you can add it to your gradle setup via:
repositories {
  maven {
    url "file:///<path to the unzipped folder>"
  }
}
These artifacts are versioned as a combination of the current version + buildid (e.g. 0.1.0-alpha01-build_123). You can find the version in the zip file by checking the contents of it and update your build file to match that version.
OK, now onto github packages - with this change, do we always overwrite the SNAPSHOT? so if I have a PR in development, and I push a new commit it will overwrite the github packages?

Another thing we might need to be careful about is just any incurred cost - github.com/features/packages#pricing. With our repo under google organisation I'm hoping that we'll be covered by the google organisation quota/allowance. But I will investigate.

the old version will be kept as you can see here:
https://github.com/icrc-fdeniger/android-fhir/packages/2129825
It's a kind of feature as we can use a specific SNAHPSHOT Version.

So yes it could be an issue with the storage. It seems there are no perfect solution for this point:
https://github.com/orgs/community/discussions/48971

jingtang10 · 2024-06-06T10:07:47Z

Thansk @icrc-fdeniger for this contribution! 🙏
For some background on the maven-repository.zip artifact, see this PR from @yigit: #249. We also have some documentation and I just realised it's a bit messed up after our recent documentation migration to this page: google.github.io/android-fhir/contrib but for your information the original text is this:
Use unreleased GitHub build (for development/testing only)
Each GitHub build of the project also contains a maven repository. You can access unreleased features by downloading it and including it in your project. To acquire the maven repository, go the the actions page, and click on the build you want. In the build artifacts dropdown, you will find a maven-repository.zip file. After downloading and extracting it to a local folder, you can add it to your gradle setup via:
repositories {
  maven {
    url "file:///<path to the unzipped folder>"
  }
}
These artifacts are versioned as a combination of the current version + buildid (e.g. 0.1.0-alpha01-build_123). You can find the version in the zip file by checking the contents of it and update your build file to match that version.
OK, now onto github packages - with this change, do we always overwrite the SNAPSHOT? so if I have a PR in development, and I push a new commit it will overwrite the github packages?
Another thing we might need to be careful about is just any incurred cost - github.com/features/packages#pricing. With our repo under google organisation I'm hoping that we'll be covered by the google organisation quota/allowance. But I will investigate.
the old version will be kept as you can see here: https://github.com/icrc-fdeniger/android-fhir/packages/2129825 It's a kind of feature as we can use a specific SNAHPSHOT Version.

So yes it could be an issue with the storage. It seems there are no perfect solution for this point: https://github.com/orgs/community/discussions/48971

is there a way to publish a github package on whatever is on HEAD? i feel like that's much more useful?

@icrc-fdeniger have you tested that the current local packages (what i mentioned above) are generated in your forked repo? I'm not seeing any successful github build actions?

See https://github.com/icrc-fdeniger/android-fhir/actions/runs/8798380904/job/24145256498 for a full deployment

this run seems to have failied?

also can you update the description to clarify when the packages are generated? is it on every github action run? will different branches and prs overwrite each other's packages?

vorburger · 2024-06-06T11:21:42Z

also can you update the description to clarify when the packages are generated? is it on every github action run? will different branches and prs overwrite each other's packages?

How about, instead of capturing this with comments here, contributing (in this PR) clarifications for any questions related to all this in a snapshot.md (or whatever) doc in https://github.com/google/android-fhir/tree/master/docs/contrib? (And link it in mkdocs.yaml.

icrc-fdeniger · 2024-06-06T11:31:54Z

Thansk @icrc-fdeniger for this contribution! 🙏
For some background on the maven-repository.zip artifact, see this PR from @yigit: #249. We also have some documentation and I just realised it's a bit messed up after our recent documentation migration to this page: google.github.io/android-fhir/contrib but for your information the original text is this:
Use unreleased GitHub build (for development/testing only)
Each GitHub build of the project also contains a maven repository. You can access unreleased features by downloading it and including it in your project. To acquire the maven repository, go the the actions page, and click on the build you want. In the build artifacts dropdown, you will find a maven-repository.zip file. After downloading and extracting it to a local folder, you can add it to your gradle setup via:
repositories {
  maven {
    url "file:///<path to the unzipped folder>"
  }
}
These artifacts are versioned as a combination of the current version + buildid (e.g. 0.1.0-alpha01-build_123). You can find the version in the zip file by checking the contents of it and update your build file to match that version.
OK, now onto github packages - with this change, do we always overwrite the SNAPSHOT? so if I have a PR in development, and I push a new commit it will overwrite the github packages?
Another thing we might need to be careful about is just any incurred cost - github.com/features/packages#pricing. With our repo under google organisation I'm hoping that we'll be covered by the google organisation quota/allowance. But I will investigate.
the old version will be kept as you can see here: icrc-fdeniger/android-fhir/packages/2129825 It's a kind of feature as we can use a specific SNAHPSHOT Version.
So yes it could be an issue with the storage. It seems there are no perfect solution for this point: github.com/orgs/community/discussions/48971
is there a way to publish a github package on whatever is on HEAD? i feel like that's much more useful?

@icrc-fdeniger have you tested that the current local packages (what i mentioned above) are generated in your forked repo? I'm not seeing any successful github build actions?

See icrc-fdeniger/android-fhir/actions/runs/8798380904/job/24145256498 for a full deployment

this run seems to have failied?

also can you update the description to clarify when the packages are generated? is it on every github action run? will different branches and prs overwrite each other's packages?

it's failing because of the feature "git pages" that I didn't activate on my repo. I tested it on April on my branch master-deploy-repo. To do the PR I had to revert my "test setup" :
icrc-fdeniger@8293430

You can have a look here:
https://github.com/icrc-fdeniger/android-fhir/actions/runs/8798380904/job/24145256498
and here:

The publication is working. If you want I can modify the github actions on my branch to show that the action will be launched for every push on master-deploy-repo and it's ok.

If the PR is accepted as is on the official repo, The publish task is launched automatically for all push to master only ( so when a PR is merged on master branch). For PR, the task will be skipped:
https://github.com/icrc-fdeniger/android-fhir/blob/6cc76eec4476188bce55a455755968fa97a38cfb/.github/workflows/build.yml#L79

icrc-fdeniger · 2024-06-06T11:34:51Z

also can you update the description to clarify when the packages are generated? is it on every github action run? will different branches and prs overwrite each other's packages?

How about, instead of capturing this with comments here, contributing (in this PR) clarifications for any questions related to all this in a snapshot.md (or whatever) doc in master/docs/contrib? (And link it in mkdocs.yaml.

@vorburger I should create a new file shapshot.md in docs/contrib and add a line related to this in mkdocs.yml and in the sections "Contributors". Am I correct ?

vorburger · 2024-06-06T11:36:58Z

@vorburger I should create a new file shapshot.md in docs/contrib and add a line related to this in mkdocs.yml and in the sections "Contributors". Am I correct ?

Yup, exactly; that's how you can contribute documentation! (If you want to, this is a suggestion.) You can name the MD file with any filename you like, obviously.

push artifacts to github Packages

bb56824

icrc-fdeniger marked this pull request as ready for review April 23, 2024 10:22

icrc-fdeniger requested review from santosh-pingle and a team as code owners April 23, 2024 10:22

icrc-fdeniger requested a review from ktarasenko April 23, 2024 10:22

vorburger approved these changes Apr 23, 2024

View reviewed changes

icrc-fdeniger force-pushed the master-deploy-repo branch from 5531d56 to bb56824 Compare May 9, 2024 20:31

icrc-fdeniger added 3 commits May 9, 2024 22:32

push artifacts to github Packages

8293430

Merge remote-tracking branch 'origin/master-deploy-repo' into master-…

3e5fa81

…deploy-repo

try to use github.run_id

3aab8f7

try to use github.run_id

dc5dca4

vorburger added the kokoro:force-run label May 10, 2024

android-fhir-bot removed the kokoro:force-run label May 10, 2024

MJ1998 reviewed May 13, 2024

View reviewed changes

buildSrc/src/main/kotlin/Releases.kt Outdated Show resolved Hide resolved

buildSrc/src/main/kotlin/Releases.kt Show resolved Hide resolved

modify comments as suggests by MJ1998

5e0dfa2

MJ1998 reviewed May 14, 2024

View reviewed changes

buildSrc/src/main/kotlin/Releases.kt Outdated Show resolved Hide resolved

MJ1998 approved these changes May 23, 2024

View reviewed changes

buildSrc/src/main/kotlin/Releases.kt Outdated Show resolved Hide resolved

buildSrc/src/main/kotlin/Releases.kt Outdated Show resolved Hide resolved

Merge branch 'master' into master-deploy-repo

295b1df

MJ1998 requested review from aditya-07 and jingtang10 as code owners May 23, 2024 05:11

MJ1998 enabled auto-merge (squash) May 23, 2024 05:11

icrc-fdeniger and others added 2 commits May 30, 2024 16:14

Merge remote-tracking branch 'origin/master-deploy-repo' into master-…

fe290b3

…deploy-repo # Conflicts: # buildSrc/src/main/kotlin/Releases.kt

Merge branch 'master' into master-deploy-repo

484f4b5

MJ1998 added the kokoro:force-run label Jun 4, 2024

android-fhir-bot removed the kokoro:force-run label Jun 4, 2024

jingtang10 reviewed Jun 5, 2024

View reviewed changes

icrc-fdeniger and others added 3 commits June 6, 2024 09:28

Merge remote-tracking branch 'origin/master-deploy-repo' into master-…

02c1ab0

…deploy-repo

Merge branch 'master' into master-deploy-repo

ba30851

Merge remote-tracking branch 'origin/master-deploy-repo' into master-…

7b4b8c8

…deploy-repo

revert changes as required

6cc76ee

auto-merge was automatically disabled June 6, 2024 07:41
Head branch was pushed to by a user without write access

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

#2503 push SNAPSHOT Maven artifacts to github Packages #2525

#2503 push SNAPSHOT Maven artifacts to github Packages #2525

icrc-fdeniger commented Apr 23, 2024 •

edited

vorburger left a comment

icrc-fdeniger commented May 6, 2024

vorburger commented May 6, 2024

icrc-fdeniger commented May 9, 2024

vorburger commented May 10, 2024

MJ1998 left a comment

MJ1998 commented May 13, 2024

MJ1998 left a comment

icrc-fdeniger commented May 31, 2024

jingtang10 left a comment

jingtang10 Jun 5, 2024

jingtang10 Jun 5, 2024

MJ1998 Jun 6, 2024 •

edited

icrc-fdeniger Jun 6, 2024

jingtang10 Jun 6, 2024

vorburger Jun 6, 2024

MJ1998 commented Jun 6, 2024 •

edited

icrc-fdeniger commented Jun 6, 2024

jingtang10 commented Jun 6, 2024

vorburger commented Jun 6, 2024 •

edited

icrc-fdeniger commented Jun 6, 2024

icrc-fdeniger commented Jun 6, 2024

vorburger commented Jun 6, 2024 •

edited

#2503 push SNAPSHOT Maven artifacts to github Packages #2525

Are you sure you want to change the base?

#2503 push SNAPSHOT Maven artifacts to github Packages #2525

Conversation

icrc-fdeniger commented Apr 23, 2024 • edited

vorburger left a comment

Choose a reason for hiding this comment

icrc-fdeniger commented May 6, 2024

vorburger commented May 6, 2024

icrc-fdeniger commented May 9, 2024

vorburger commented May 10, 2024

MJ1998 left a comment

Choose a reason for hiding this comment

MJ1998 commented May 13, 2024

MJ1998 left a comment

Choose a reason for hiding this comment

icrc-fdeniger commented May 31, 2024

jingtang10 left a comment

Choose a reason for hiding this comment

jingtang10 Jun 5, 2024

Choose a reason for hiding this comment

jingtang10 Jun 5, 2024

Choose a reason for hiding this comment

MJ1998 Jun 6, 2024 • edited

Choose a reason for hiding this comment

icrc-fdeniger Jun 6, 2024

Choose a reason for hiding this comment

jingtang10 Jun 6, 2024

Choose a reason for hiding this comment

vorburger Jun 6, 2024

Choose a reason for hiding this comment

MJ1998 commented Jun 6, 2024 • edited

icrc-fdeniger commented Jun 6, 2024

jingtang10 commented Jun 6, 2024

vorburger commented Jun 6, 2024 • edited

icrc-fdeniger commented Jun 6, 2024

icrc-fdeniger commented Jun 6, 2024

vorburger commented Jun 6, 2024 • edited

icrc-fdeniger commented Apr 23, 2024 •

edited

MJ1998 Jun 6, 2024 •

edited

MJ1998 commented Jun 6, 2024 •

edited

vorburger commented Jun 6, 2024 •

edited

vorburger commented Jun 6, 2024 •

edited