Since passing CI is a prerequisite for any PR to be merged, the post merge CI invocation is not really about testing the code. In actuality, the post merge CI invocation is to make sure that the production engine container image repository is populated with as many of the images as possible.
Based on the above premise, it is only necessary to run the post merge CI when there are changes that do or could result in the building of new engine container images. Thus, refactor each subproject's crucible-merged.yaml file to only run the workflow when changes to that subproject could result in that type of activity.
This should reduce the number of invocations of crucible-merged.yaml which should in turn reduce wasted executions and free up the finite runner resources that we have to focus on running jobs that are truly necesssary.
Since passing CI is a prerequisite for any PR to be merged, the post merge CI invocation is not really about testing the code. In actuality, the post merge CI invocation is to make sure that the production engine container image repository is populated with as many of the images as possible.
Based on the above premise, it is only necessary to run the post merge CI when there are changes that do or could result in the building of new engine container images. Thus, refactor each subproject's crucible-merged.yaml file to only run the workflow when changes to that subproject could result in that type of activity.
This should reduce the number of invocations of crucible-merged.yaml which should in turn reduce wasted executions and free up the finite runner resources that we have to focus on running jobs that are truly necesssary.