-
Notifications
You must be signed in to change notification settings - Fork 24
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Check if another PR exists to cancel a build #200
Comments
@Ginxo |
I like your proposal!! 🤟 |
thinking about this double... it's a good thing to have, but don't you think were are breaking the single-responsability principle here 🤔 we are talking about jobs here and how to handle them in a more efficient way which is great and I'm ok with it, but I wouldn't delegate this responsibility to build-chain since its execution is just part of the job itself. I would bet to move the functionality you (we) require to the job but to this tool. |
now how to do it from the job configuration...? I don't know and that's probably the reason why we are discussing to move it here... I don't see any other option but to move it here (or to a different tool, but somehow here) |
Once we get the list of repositories to be checked it would be about getting the workflows from those repositories like
then getting the jobs for this particular branch and this particular workflow https://api.github.com/repos/kiegroup/droolsjbpm-build-bootstrap/actions/runs?event=pull_request&branch=dependabot/maven/org.jsoup-jsoup-1.14.2&status=in_progress (probably use Note: the only (best) way to identify similar workflows is by the name, so workflows to be cancelled should share the same name
and then from
Filtering the steps by name (names should match) Note: It could be the case where two jobs from different repositories are checking each other at the same time and both of them are cancelled. I don't really know how to solve this scenario, any idea @danielezonca |
In Kogito we are creating multiple jobs for each PR to test in parallel different repos and see if the change breaks one of the downstream components. This is useful but it is not necessary if it is a multi repo PR because the same build will be executed also from that repo so it is a very inefficient way to use the (limited) GitHub action executors that we have.
i.e. https://github.com/kiegroup/kogito-runtimes/pull/1703
i.e. in this case OptaPlanner job https://github.com/kiegroup/optaplanner/pull/1662
It should be useful to have an optional check that for each job:
starting-project
sourceRepo:sourceBranch
and the sametargetRepo:targetBranch
exists for that projectThis check has to be opt-it (like
skip-if-duplicated : true
)I was thinking about creating a different action for this but it is strictly related to the
github-build-chain
because it has to know which is the target project that could be different from the current repo (i.ekogito-apps
build inkogito-runtimes
repo)The text was updated successfully, but these errors were encountered: