GHA Updates

[pSchlarb]

To use the indy-test-automation in the New Release workflow from indy-node
the following needs to be done:

• Exchange the currently used docker image in system_node_only/docker/node with a new one.
  The new one should install the needed packages by .deb packages downloaded urls ( most likely from the github releases from node and plenum). These urls should be parametrized.
  Therefore the GHA in node and plenum also need to be edited.
• Refactoring of the GHA in indy-test-automation to be useable with the
  workflow-call-trigger from other repositories (mainly indy-node). The urls for the deb packages should be used as inputs.
• Change of node and plenum GHA to use the repository-dispatch-trigger workflow for node
  (needs to be done after the ubuntu20.04-upgrade branch becomes main).
  In example an update of plenum should trigger the repository-dispatch of node, wich then tests the new version with indy-test-automation
• Refactoring of the GHA in indy-test-automation to be useable with the
  workflow-call-trigger from other repositories (mainly indy-node). The urls for the deb packages should be used as inputs.
• Update indy-node GHA for the release testing (releasepr.yaml) to test with indy-test-automation

Developing has been started in:
https://github.com/pSchlarb/indy-test-automation/tree/GHA
https://github.com/WadeBarnes/docker-container-testing

For node and plenum the corresponding changes has been marked WIP.

[WadeBarnes]

The specific file in WadeBarnes/docker-container-testing to reference is Dockerfile.node.fromdeb.ubuntu2004. It provides a PoC of how to install the plenum and node deb packages directly. This is an important step that allows indy-test-automation to test the packages before they are published to the official repositories.

[udosson]

@WadeBarnes @pSchlarb
Is there a way to get the .deb packages from Indy Node and Plenum without releasing them as a file? Can we access the artifacts or the cache of the root GHA when using the workflow-call trigger?

[pSchlarb]

Hm inside one repository it possible to access the artifacts from another pipeline (https://github.com/hyperledger/indy-plenum/blob/ubuntu-20.04-upgrade/.github/workflows/publishRelease.yaml#L53-L60).
Our idea was to use the github prereleases and pass the url for these artifacts down the line.

workflow_call is used to indicate that a workflow can be called by another workflow. When a workflow is triggered with the workflow_call event, the event payload in the called workflow is the same event payload from the calling workflow. For more information see, "Reusing workflows."
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_call

Can we access the artifacts or the cache of the root GHA when using the workflow-call trigger?

Yes it is possible https://github.com/hyperledger/indy-shared-gha/blob/main/.github/workflows/publish_artifacts.yaml#L48-L52 downloads the Artifacts from the caller Workflow(node or plenum), which have been uploaded by a called workflow(buildpackages from shared-gha).

[udosson]

Should we go with pre-releases or should we download the artifacts? I'm okay with both and maybe find some time this or next week

[pSchlarb]

I am in favor for the fully automated version, that uses the pipeline artifacts.
With the workflow_call the workflow can reside inside the indy-test-automation repo and can be called and executed from the node workflows. The positive side of that is, that the execution of indy-test-automation can therefore be used to gate the releases of node.