added spec compliance check badge

[Xerner]

The actual implementation and one-time steps necessary for this to work are located here eclipse-uprotocol/ci-cd#23

addresses #282

See schneegans/dynamic-badges-action/tree/v1.7.0 for more info on how this works

[sophokles73]

Hey @Xerner, this is a nice idea and should work for information that we only ever need to determine for the HEAD revision of the main branch. However, my understanding is that all revisions of our README.md file (in the up-rust repo) will always refer to the same badge definition file in the gist repo, and thus they will all indicate the same (latest) version of up-spec, or am I mistaken? If so, this would mean that if I go to an older tag in the up-rust repo, the README.md would still contain a badge that would indicate the crate implementing the most recent version of up-spec, right?

[Xerner]

Hey @Xerner, this is a nice idea and should work for information that we only ever need to determine for the HEAD revision of the main branch. However, my understanding is that all revisions of our README.md file (in the up-rust repo) will always refer to the same badge definition file in the gist repo, and thus they will all indicate the same (latest) version of up-spec, or am I mistaken? If so, this would mean that if I go to an older tag in the up-rust repo, the README.md would still contain a badge that would indicate the crate implementing the most recent version of up-spec, right?

Correct. If we wish to track historical up-spec version compatability badges when looking at past revisions, then the github action would have to commit a change directly in the README.md file to update the badge. No Gist would be used, and the badge would be a static image link. It would mean adding a commit every time the up-spec submodule changes its referenced commit. I see no issue with this

[AnotherDaniel]

One thing that I wonder - without having looked at the details of this PR, I will do that asap - might this information (supported-spec-version) be a good datum to go into its own little text file, top-level of the repo? I'm thinking of a few use cases we could build on this, more easily than if the information was directly buried in the README:

• (put it in the README, of course)
• put it into metadata of packages when they are being published (e.g. to crates.io)
• have a dedicated little file that I can use in my TSF workflows
• have the supported-spec-version in a clearly defined and generic place, where we can e.g. then build a collection script to run through all the repos in uProtocol, and auto-generate an spec-coverage table

[Xerner]

Converting this into a draft until a decision is made on exactly how the badge should be applied to the README.md file.

Currently known strategies for applying a status badge are

• A staticly defined status badge in the README.md that reads its values from a GitHub Gist (a JSON file that lives on GitHub's servers). Then, on the CI/CD run that determines the up-spec compliance, the GIST is updated. This updates the status badge. This also means all branches share the same badge status, but it removes the need to give the CI/CD run permissions

• A CI/CD run determines the up-spec compliance, and commits a new status badge to the README if needed. This requires the CI/CD run to have proper permissions to commit

• TODO: Open a new PR to create a CI/CD run that runs the compliance check, but does not create the badge. It will simply pass/fail if the up-spec is compliant or not, and print the current up-spec submodules version in its run logs.

[sophokles73]

Hi @Xerner,

we already have a (reusable) GitHub workflow that checks compliance with the current/latest spec. You can refer to the nightly.yaml workflow definition for details.