The only issue with this is that if I dont add the last step Bitrise Wait for build:
The PR workflow runs
Starts the others jobs and enqueue them and success
I see in the PR that it went good but the other ones are still running.
And if I have this Bitrise Wait for build then I dont have any concurrency, because this workflow stays active and use 1 of the “concurrency slots”, and so I just have another one, and at the end that’s not any concurrency because I just have 1 workflow running at the time like this:
You can have more concurrencies if you have an Organization with an active plan. Since you only have one concurrency, you will not be able to properly utilize the Bitrise Wait for build step, as it would rely upon having more than one concurrency at a time.
But what you can also do is to instead of having a Bitrise Wait for build step at the end of your workflow, is to have a git status step at the end of each workflow you start and trigger (we have steps for most git repository providers: Github, Gitlab, Bitbucket and Azure DevOps). If you search for ‘status’ in your workflow editor, you should see all the options!
This would cause your builds to report back to your git account individually, so you could see which ones were successful.