[INFRA] add automation to the examples repository release part

[tbouffard]

Currently, we have to manage the examples repository manually as described in https://github.com/process-analytics/bpmn-visualization-js/blob/v0.8.0/docs/contributors/maintainers.md

The macro steps are

• locally in a specific branch
  • run a script
  • update the demo part by downloading it
• create a Pull Request
• do manual tests

Except for the tests part (which we will address eventually later), we should be able to automate everything to have the Pull Request.
This would help avoiding issue like the one we had after the 0.8.0 release, see process-analytics/bpmn-visualization-examples#110

Additional Context
When implementing, remember that we have a playground repository to test and poc the workflows.

Proposals to be discussed

Notes: more solutions are going to be proposed

Solution 1: on tag, build demo and trigger a new workflow in the examples repository

What we have now: the demo is built on master push and tag, and it is archived as a GH Actions artifact.

Proposed solution

• on tag in the lib repository, trigger the run of a new workflow hosted in the examples repository via a workflow_dispatch event
• in the examples repo, have a workflow_dispatch (can be triggered manually or from the lib repo) which would do what we manually do
  • configure git locally to act as the process-analytics-bot user
  • run the script
  • retrieve the demo built on tag in the lib repository. It could be pass as an input of the workflow_dispatch: tag value or url
  • create pull request: an action like https://github.com/marketplace/actions/create-pull-request

About what triggers the examples workflow
For a better understanding, we should probably avoid triggering it from the generate demo for a better separation of concern
We could stop building the demo on tag in the regular 'build demo' workflow and create a new specific workflow in charge of managing the example: prepare data (the demo) and trigger the
This new workflow could also be run manually on demand if we configure it to be trigger on workflow_dispatch with the version (in x.y.z format) as input parameter

About the demo retrieval
This is the part we have to investigate, mainly to be able to know if we can have a demo artifact download url or an artifact id.
See

• https://docs.github.com/en/free-pro-team@latest/rest/reference/actions#download-an-artifact
• https://docs.github.com/en/free-pro-team@latest/actions/guides/storing-workflow-data-as-artifacts
• Why is artifact download url to be expired in 1 minute?  actions/upload-artifact#60
• Support artifact URL output actions/upload-artifact#50
• https://github.com/JayFoxRox/GitHub-artifact-URL

Passing the tag would make manual run easier, this is a nice to have. It implies being able to retrieve the GH worfklow run with the tag then retrieve the artifact url.

Solution 2: the lib release workflow also update the examples repositories

To be checked if we have issue with Solution 1 (mainly on the demo download part)

• Pros: less investigation, could be a 1st implementation
• Cons: less separation between the 2 repositories

Changes compared to Solution 1

• do what we plan for solution 1, but don't trigger the workflow in the examples repo
• instead add a new job/steps to manage the examples repo update directly here
• for the demo artifact retrieval, we can directly use the download artifact action
• we should create an overall script in the examples repository to manage most of the job to avoid spreading logic in the lib repository. This should make maintenance easier

[aibcmars]

I like Solution 1

autonomous workflow_dispatch in bpmn-visualization-examples repository
triggered by the tag in bpmn-visualization-js repository

[csouchet]

I prefere the first solution to keep separation between the 2 repo 🙂