Right Eclipse Zenoh has two development branches: main and dev/1.0.0. Nightly Release workflow dry-runs are only scheduled for the main branches. Thus a flexible way to perform a dry-run on all repositories is needed.
Idea 1: Reusing workflows (won't work)
We could add a release.yml workflow in this repository which calls all Release workflows. This has the added benefit of more easily tracking multi-repository dry-run workflow execution.
A subsequent release-nightly.yml workflow can then reuse the release.yml workflow by triggering it on multiple branches.
GitHub Actions only allows 4 levels of re-usable workflow nesting. Release workflows reuse this repository's workflows (level 1), we would in turn reuse those in this repository's release.yml (level 2) and finally reuse this release.yml in release-nightly.yml (level 3). Some of this repository's workflows reuse each other so we're technically at level 4. This can be easily fixed by inlining the workflow actions.
While writing this I realized that since we're only allows 20 maximum reusable workflows including trees of reusable workflows this solution isn't viable; plugin & backend workflows call 8-9 worflows. So we would hit the limit with only 2 such repositories.
Idea 2: Using the gh CLI
It's possible to trigger workflow runs using gh workflow run. While this gets the job done, it doesn't provide any progress report on the workflow execution. For that we would need to call gh run watch and wait for its process to finish.
This is problematic because gh workflow run doesn't return the id of the triggered workflow so we would have to infer it using gh run list. This is not ideal since we could have multiple recently triggered workflows and we wouldn't know which one we triggered.
Problem
Right Eclipse Zenoh has two development branches:
mainanddev/1.0.0. Nightly Release workflow dry-runs are only scheduled for themainbranches. Thus a flexible way to perform a dry-run on all repositories is needed.Idea 1: Reusing workflows (won't work)
We could add a
release.ymlworkflow in this repository which calls all Release workflows. This has the added benefit of more easily tracking multi-repository dry-run workflow execution.A subsequent
release-nightly.ymlworkflow can then reuse therelease.ymlworkflow by triggering it on multiple branches.GitHub Actions only allows 4 levels of re-usable workflow nesting. Release workflows reuse this repository's workflows (level 1), we would in turn reuse those in this repository's
release.yml(level 2) and finally reuse thisrelease.ymlinrelease-nightly.yml(level 3). Some of this repository's workflows reuse each other so we're technically at level 4. This can be easily fixed by inlining the workflow actions.While writing this I realized that since we're only allows 20 maximum reusable workflows including trees of reusable workflows this solution isn't viable; plugin & backend workflows call 8-9 worflows. So we would hit the limit with only 2 such repositories.
Idea 2: Using the
ghCLIIt's possible to trigger workflow runs using
gh workflow run. While this gets the job done, it doesn't provide any progress report on the workflow execution. For that we would need to callgh run watchand wait for its process to finish.This is problematic because
gh workflow rundoesn't return the id of the triggered workflow so we would have to infer it usinggh run list. This is not ideal since we could have multiple recently triggered workflows and we wouldn't know which one we triggered.