Consume GitHub releases

[migmartri]

We want to be able to attest a gitHub release in an easy way.

Ideally, we could have a reusable workflow/action that reacts to a release event and performs an attestation of all the published artifacts.

As explained here #772 (comment) we can download all the artifacts using the GH CLI, and then we could push them to Chainloop by using a CHAINLOOP_TOKEN

We could even automatically create a workflow if needed using also our new reusable workflow for that purpose cc/ @jiparis

Tasks

Beta Give feedback

1. Allow adding arbitrary materials to an attestation #786
   component/backend +1
   
2. Think about autodiscover material type #816
   component/backend +1
   
3. Implement attestation workflow #788
   component/backend +1
   
4. Show public attestation URL in the release notes #787
   component/backend +1
5. Make it a reusable workflow, implement it and document it #844
   component/backend +1
   
6. add guard to check it's a release
7. Document it in docs #849
   documentation +1
   
8. Make reusable workflow work without write permissions #852
   component/backend +1
   
9. Be able to configure the output of contract-less materials
10. Modify existing release contracts?
11. Attestation result output for contract-less materials #866
    component/backend good first issue +2
12. Add goreleaser as new material kind #867
    component/backend good first issue +2
13. Allow material's outputs configuration. #868
    component/backend good first issue +2

[javirln]

One of the issues found when deploying the reusable workflow into our pipelines is the fact that a workflow cannot be triggered by other workflow if the token used is the default GitHub token. That provoked that the build and package workflow didn't the release workflow since, what triggers a release within build and package is goreleaser using a GitHub Token.

More information regarding the issue can be found here: https://docs.github.com/en/actions/using-workflows/triggering-a-workflow#triggering-a-workflow-from-a-workflow

This does not mean the workflow does not work, it only means that in order to be triggered by another workflow it needs to use a personal access token, manual releases of course trigger the workflow.

We need to update the documentation to reflect this edge case.

[migmartri]

Should we support workflow dispatch? That one seems to be supported.

[javirln]

Additionally to the release trigger? It's supported by a GitHub token I believe will do anything to that workflow since it's manually triggered no?

How do you think it would be the flow for our use case? Once build and package is finished, us manually going to the workflow and trigger it? In that case we need to check that the github.ref_name is still the tag

[migmartri]

basically, the reusable workflow uses a tag as input. Then this workflow can be used from different parent jobs, either by being triggered explicitly or in a workflow that reacts to the release event.

Either way, the reusable workflow is the same but gets triggered/loaded in two different contexts, does it make sense?

[javirln]

Closing this task in favor of its follow up one: #869

Additionally the following issues should be considered once tackling that task since they were not part of this one:

• Attestation result output for contract-less materials #866
• Add goreleaser as new material kind #867
• Allow material's outputs configuration. #868