feat: add latest-snapshot as a badge in README.md #2247
Conversation
BrunoMiguelNogueira
requested review from
rafaelmag110,
lgblaumeiser and
bmg13
as code owners
BrunoMiguelNogueira
force-pushed
the
latest-available-snapshot-as-badge
branch
2 times, most recently
from
7aa2d87 to
3255861
Compare
|
just reviewed and am okay to merge, just please update the description with an image of the outcome so that there are no surprises. |
There was a problem hiding this comment.
Thanks for the contribution, unfortunately, this is not what was intended with the issue. The problem is, that the central snapshot repository does not allow to browse anymore. Therefore, it is not easily possible to determine the latest versioned snapshot.
The idea was, to intergrate something into the github workflow which actually pushes the artifacts to central maven snapshot repository, as this workflow knows which version it has just pushed.
|
@lgblaumeiser I see your point here, still I would consider the value added by this PR. |
But that is just information that you can see from a static file in the repository. It is only one line of code, but it needs to be managed and if it fails, time needs to be spend to fix it. For me, it is not enough benefit to have it, to be honest. |
|
But that seems to be actually what was decided in this issue #2076 (comment).
And seems to be what is implemented in this PR. |
Hi @bmg13, that is the misunderstanding, the issue is about the latest versioned snapshot available for dependency resolving for adoptors, i.e., in maven central. We build a 0.11.0-20250915-SNAPSHOT version which we ship now to maven central instead of previously the ossh repository. The issue is, that the snapshot repo in maven central does not allow browsing, at least when I last looked at, due to security reasons. So if someone wants to update dependencies to our latest snapshot, he has no way of finding out the exact version string, so he can not update to the snapshot. The idea of the issue was, that we provide information on published versioned snapshots in the repository and Rafael and I agreed to only point out the last published snapshot, not a list of available ones. This is why I request changes, because the solution in the PR does not meet the requirement expressed in #2076, which is, telling people which version string to use, if they, e.g., want to create their own connector runtime pointing to the maven central snapshot repository for resolving dependencies. |
BrunoMiguelNogueira
force-pushed
the
latest-available-snapshot-as-badge
branch
from
75a0db3 to
3255861
Compare
|
@lgblaumeiser I think I’m starting to get a clearer idea of what you want as a solution, though I still have some questions. After reviewing the actions and the way we create snapshots in the format you call versioned, I’ve identified two options:
When I check the old repository’s entries and timestamps, it seems that the badge should update with both types of snapshot creation. Is this correct? I believe there are two scenarios the badge should cover:
Additionally, the badge mustn’t update if the snapshot is not versioned. Do these scenarios cover what you had envisioned as a solution? |
|
Hi @BrunoMiguelNogueira, see my answers below
The badge should reflect the last versioned snapshot build, whether done manually or scheduled does not matter.
I would say, that it should keep the old content. It should always point to the last available versioned snapshot, why versioned, because this is stable, as a user that wants to test something can depend on a non-changing thing. Depending on the last unversioned snapshot adds changes under the hood, which is not wanted in such a scenario, right. The last versioned one is the best we can offer, if an upload failed, we cannot provide a better version, but the old is still there.
Exactly as motivated in the last point, right? |
BrunoMiguelNogueira
force-pushed
the
latest-available-snapshot-as-badge
branch
from
3255861 to
85ef787
Compare
|
Please retry analysis of this Pull-Request directly on SonarQube Cloud |
| if [ -n "$UPDATE_BADGE" ]; then | ||
| sed -i "s|^\[snapshot-shield\]:.*|[snapshot-shield]:https://img.shields.io/badge/latest--snapshot-$ESCAPED_VERSION-blue?style=for-the-badge|" 'README.md' | ||
| fi | ||
| - name: Commit changes |
There was a problem hiding this comment.
That is not the best practice, as badge changes should not create a trace in the repositories history. I found several solutions for such badges which provide the data using an api that stores the intermediate value. I think I remember, that it is possible to use an workflow artifact that is used as data, or something like that.
And please take care, that the file end with a newline, thanks!
There was a problem hiding this comment.
I’ve looked into it and haven’t found a way to do this without a commit or new dependencies.
Since the version is only defined within the Action:
• Static badge: We would need to commit the updated version each time (current approach).
• Dynamic badge: We would need a publicly accessible data source fed from the Action.
From what I understand, Action outputs and artifacts cannot be accessed publicly, so the version must be persisted somewhere accessible to use it for a dynamic badge.
That leads us back to the commits, and the only way this wouldn't leave a trace in tractus would be by using an external storage, which would add a dependency.
If you have any other possibility that you would like me to try and explore let me know.
|
WHAT
Adds the latest stable snapshot version to README as a badge.
WHY
Due to security reasons, Sonatype removed browsing of central.sonatype.com/repository/maven-snapshots.
FURTHER NOTES
Since we have no way of accessing the snapshot's repository, the badge uses the already existing version value from the latest stable upload.
(example)
Closes