Do not create a new scratch org but use the previously created

[fprovot]

Each run of rupertbarrow/cumulus-action-run-flow-scratch create a new scratch org, while it should reuse the one created at the first run . (even with version "6-make-deletion-of-scratch-org-optionnal" , and even when removing the Delete Scratch Org step, that is then indeed not executed, so nothing in the logs do a delete scratch org)

Comment from Jason Lantz

"
Where are you running the ci_feature flow? I'm guessing you're using the cumulus-actions reusable workflows for GitHub Actions? If so, rewiring how those work can involve forking a lot of different repositories to get all the layers to where you can change how they work together.

From your logs, wherever you are running ci_feature from doesn't seem to have a release_eu scratch org created in its keychain which is why it tries to create one. CumulusCI's scratch orgs are more like a lazy profile to create an org. When you try to run something against them, they wake up and reuse an existing scratch org if one exists and if not will spin up a scratch org.

There's nothing in any of the CumulusCI flows that will delete a scratch org so that must be coming from a build script of some kind.
"

See https://trailhead.salesforce.com/fr/trailblazer-community/feed/0D54V00007QfDN0SAN

[fprovot]

@RupertBarrow This strange problem is annoying

[RupertBarrow]

Fred,
Please share some logs or pointer to a workflow run.

[fprovot]

Last Example
1 hour ago https://github.com/Flowbird-Corp/MAP_CSU/actions/runs/6982670189/job/19002290292
next run now : https://github.com/Flowbird-Corp/MAP_CSU/actions/runs/6983268286
(not sure the second will not fail because it may wait for another running action and the branch may be closed too soon...)

[fprovot]

Other examples older, the same day:

https://github.com/Flowbird-Corp/MAP_CSU/actions/runs/6905917194
https://github.com/Flowbird-Corp/MAP_CSU/actions/runs/6906913239