added spec version and compliance check badge

[Xerner]

This PR adds a workflow that adds badges that show

• whether the current commit is on the latest up-spec version
• whether the current commit is up-spec compliant. This makes use of the existing requirement-tracing workflow

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

addresses #282

[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.

  • this was addressed by https://github.com/eclipse-uprotocol/ci-cd/blob/main/.github/workflows/requirements-tracing.yaml**
  • I also added an action in the CI/CD repo that outputs if the up-spec version is the latest or not

[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.

[PLeVasseur]

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.

Specifically, as we were chatting about in the meeting the workflow can be found here:
ci-cd/.github/workflows/requirements-tracing.yaml

[Xerner]

Note: this PR was previously named "added spec compliance check badge" but actually just added a check for the latest spec version. So, I just added an additional badge that checks up-spec compliance and renamed the PR accordingly. Might as well have both, right?

I switched my implementation from using a Github Gist to directly pushing a commit to the repo from the Github Action run.

The PR is failing because the commit is authored by [email protected], which is not an author covered by the Eclipse Fdn legal agreements. How should I go about addressing this? @sophokles73