adds quevee action to deploy action

[eriksven]

The quevee action is developed by the Eclipse Foundation to track the different Eclipse SDV badges.

The badges would then be visible here: https://metrics.eclipse.org/projects/automotive.kuksa/#tabs-project_basics-5

For this to happen, the releases need a manifest file with further information for the tooling run by the Eclipse Foundation.

[sophokles73]

Using these kinds of URLs seems problematic to me because they will resolve to different resources depending on the time of evaluation. Thus, these pointers are not tied to the revision of these resources at the point in time that the release is being created.

[eriksven]

Good finding. Unfortunately, I somehow missed your comment and then it got lost over vacation.

I did more testing with the quevee tool and adapted the action here accordingly. @sophokles73 could you please have another look?

Quevee converts references to files into static URLs with the commit hash of the tag from that release.
If there is a prefix like https://, the action does not modify the URL further.

For reference, you can see my experiments with another release.yml in a dummy repository (eriksven/process-tester). As a resulted there a now test releases

For example:

artifacts_readme: README.md

becomes

readme = [
    "https://raw.githubusercontent.com/eriksven/process-tester/e6176aafc6577bf852510f1a39b360ab1acb269f/README.md",
]

But

artifacts_release_process: https://example.org/my_release_process/${{ github.event.release.tag_name }}

converts to

release_process = [
    "https://example.org/my_release_process/v0.0.5",
]

[eriksven]

We cannot merge this PR yet because there is a finding with clippy leading to failed checks.

To me it seems that the finding is not related to this PR but due to stronger rules in clippy with more recent versions. At least on my machine the clippy commando did not have any findings with a Rust toolchain around Rust 1.87. After I upgraded my local Rust toolchain to 1.90, I got the same findings as in the build check.

[sophokles73]

the idea here is to point to an artifact that actually contains the results of running the tests, e.g. a junit test report

[eriksven]

Ok, I removed the testing entry for now. WDYT?

As of now, we do not do dedicated automated testing as part of the release workflow but as part of each PR. Thus it will be a bit more complicated to link to a resource here that contains the test results for that release. I see two approaches and would rather fix this in a dedicated PR since it goes beyond the quevee setup.

1. We execute the test suite during this release pipeline, add the resulting output as asset to the release, and add the URL to that asset in the quevee step
2. We let the release action find the last PR that has been merged to main before the execution of the release action and then reference the output of that as artifacts_testing .

I am strongly in favor of option 1.
The search for the right action in option 2 seems more error-prone and the action results might be deleted at some point.

[eriksven]

The clipper finding is fixed in #21 and I am waiting for the PR to be reviewed and merged before applying the commit here.