-
Notifications
You must be signed in to change notification settings - Fork 16
Feat/up spec badge #294
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
base: main
Are you sure you want to change the base?
Feat/up spec badge #294
Conversation
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.
Pull Request Overview
This PR adds automation to maintain the up-spec compatibility badge in the README. A GitHub Actions workflow automatically checks the project's up-spec version against the latest available release, updates the badge color accordingly (green if current, red if outdated), and commits changes to keep the documentation synchronized.
Key changes:
- Automated badge updates via GitHub Actions workflow triggered on pushes to main
- Badge generation based on git submodule tag detection and GitHub API queries
- Self-updating README with HTML comment markers for badge placement
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
.github/workflows/up-spec-badge.yml |
Implements the automated workflow to fetch up-spec versions, compare them, generate the appropriate badge, and update the README with git operations |
README.md |
Adds HTML comment markers and initial up-spec compatibility badge showing v1.6.0-alpha.7 status |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
Co-authored-by: Copilot <[email protected]>
|
Hi @senseix21 👋 did you see there was already an existing PR here? (note that I've not looked into either PR) Did this PR solve something notably different from the other one? |
|
Another request -- please sign the Eclipse Foundation's ECA so that your contributions could be merged |
|
done |
sophokles73
left a comment
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.
Thanks for the PR, this looks promising 👍
I am not too familiar with the use of the github-actions[bot] user. Will the commit created by this job be included in the list of commits from the (original) push that triggered the workflow in the first place?
|
|
||
| on: | ||
| push: | ||
| branches: [ main ] |
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.
My understanding is that the whole mechanism will (currently) only work when we make changes to the main branch. However, IMHO we will need to be able to do this on (version specific) branches as well. For example once we have released stable versions 1.0.0 and 2.0.0 which implement different versions of the spec, we will need to be able to apply this mechanism on version specific bug-fix branches. AFAICT this mechanism should generally also work in such a scenario, but will need to consider the branch that we are pushing to in several places, or am I mistaken?
|
|
||
| on: | ||
| push: | ||
| branches: [ main ] |
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.
My understanding is that the whole mechanism will (currently) only work when we make changes to the main branch. However, IMHO we will need to be able to do this on (version specific) branches as well. For example once we have released stable versions 1.0.0 and 2.0.0 which implement different versions of the spec, we will need to be able to apply this mechanism on version specific bug-fix branches. AFAICT this mechanism should generally also work in such a scenario, but will need to consider the branch that we are pushing to in several places, or am I mistaken?
| [](https://github.com/eclipse-uprotocol/up-spec/tree/v1.6.0-alpha.7) | ||
| <!-- up-spec-badge-end --> | ||
|
|
||
|
|
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 would be great if we could also update the link in the subsequent line(s) dynamically, based on the current tag ...
This pull request introduces automation to keep the
up-speccompatibility badge in theREADME.mdup to date. A new GitHub Actions workflow checks whichup-spectag the project is using, compares it to the latest available tag, and updates the badge and its color accordingly in theREADME.md. This ensures the badge always reflects the current compatibility status withup-spec.Automation and badge update:
.github/workflows/up-spec-badge.yml) that:up-spectags.README.mdand commits the change automatically.Documentation:
up-speccompatibility badge section into theREADME.md, showing the current tag and its status.