search

product-os / flowzone

Reusable, opinionated, zero-conf workflows for GitHub actions
https://flowzone.pages.dev
Apache License 2.0
15 stars 5 forks source link

Structure custom tests into reusable workflow instead of composite actions #215

Open fisehara opened 2 years ago

fisehara commented 2 years ago

Instead of structuring the custom tests to call .github/actions/tests as composite actions I'd suggest to call a reusable workflow. This will enable the custom tests to split and join parallel test scenarios. Eg. the balena-api testing will trigger all tests for each version independently to scope the failing version. This could run in parallel.

This cannot be addressed with composite actions as these are just steps without parallelism.

klutchell commented 2 years ago

We are using an action in the npm finalize job that allows copying artifacts between workflows which would be required for this.

On Mon, Sept 19, 2022, 8:12 a.m. fisehara @.***> wrote:

— Reply to this email directly, view it on GitHub https://github.com/product-os/flowzone/issues/215, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4CWICYL6RZKPFAT2HBWZLV7BKDJANCNFSM6AAAAAAQQBPKQA . You are receiving this because you are subscribed to this thread.Message ID: @.***>

fisehara commented 2 years ago

I'm sorry, but I don't understand the relation. I would rather like the custom tests to be self contained instead of relying on meta-flow artifacts? Otherwise, the custom test workflow breaks when the meta-workflow changes.

eg I want to parallelize the docker tests from the meta-workflow for the balena-api for all API versions. The artifcats don't need to be shared between the meta-workflow but the custom workflow will build the image ones and share it between parallel executions.

klutchell commented 2 years ago

But then the custom steps/jobs don't get to benefit from the versioned source provided by Flowzone?

If they don't share artifacts there is no need for any change to Flowzone. Instead just add custom reusable workflows at the repo level that are triggered when Flowzone ends. Flowzone doesn't need to know that they exist or call them for you.

We could instead provide an example of a custom workflow that triggers Flowzone which in turn triggers another custom workflow but Flowzone doesn't need to do anything to support this.

On Mon, Sept 19, 2022, 9:36 a.m. fisehara @.***> wrote:

I'm sorry, but I don't understand the relation. I would rather like the custom tests to be self contained instead of relying on meta-flow artifacts? Otherwise, the custom test workflow breaks when the meta-workflow changes.

eg I want to parallelize the docker tests from the meta-workflow for the balena-api for all API versions. The artifcats don't need to be shared between the meta-workflow but the custom workflow will build the image ones and share it between parallel executions.

— Reply to this email directly, view it on GitHub https://github.com/product-os/flowzone/issues/215#issuecomment-1251032126, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4CWIHDLN66Z5WCSMNXTFDV7BT6XANCNFSM6AAAAAAQQBPKQA . You are receiving this because you commented.Message ID: @.***>