Closed daniel-soli closed 2 years ago
Now I see how this is different from separate workflows, e.g. in my fork.
So I get the general idea, but please try to explain what needs to be changed in more detail, especially with regards to the two existing workflows that are already in place here.
I'm not always the best in explaining 😄
Take a look at my workflows in LoopStats.
Splitting CI and CD into two different workflows, basically beeing as is but adding the necessary formatting to both.
So instead of 2 workflows as it is now, it would be 4. CI and CD for dev, CI and CD for prod.
Oh well, seems I've got some digging to do.
I assume the modified workflows are only active once they've been merged into master, correct?
And the CI part could be the same for everything, i.e. including PRs, correct?
Yeah, that's a drawback... Can only test while in the environments. But could do dev first to see if all works as expected, and then just copy to prod workflows
To save me from editing the workflow actions that fudgey did back then, I just added a new specific workflow that is only triggered by pull requests on master and dev. Let's see if that is sufficient!
Oh well, first trial with #168 and the workflow wasn't triggered. No idea why, isn't it sufficient to have the workflow committed in master?
OK, merging master back into dev (#169) did the trick:
With adding a simple add job step to the workflows:
we can get these test running before a PR is done, and directly see if we have broken something.. Like this:
Would also need to split up CI/CD in seperate workflows.