Thanks for the detailed write-up. I want to make sure we solve the right problem before we scope anything.
The way I read it, the proposed run on a PR exists to show you the plan for that change. Once you merge to main, that preview is redundant, and you're left paying twice: workers running jobs that no longer matter, plus drift notifications that the incoming tracked run is about to resolve.
Here's the direction I'd like to test with you. Instead of cross-type auto-cancel, what if you could define in a policy when a proposed run should be skipped or cancelled? For example: skip PR and drift proposed runs on a stack once a tracked run for the same change is queued. Would that cover both of your cases? Or do you also need the cancel to fire when no new run starts in that evaluation phase at all?
Rose Octopus
•
Jul 7
Hey @Natalia Gazda
thanks for the answer and questions.
You understood it correctly. Here is a real scenario:
We have an open PR and want to merge it, but there are pending Spacelift proposed runs. In general, we wait until all are planned (and a PR can have several runs, when a big pr was created or e.g. files in an additional project glob was changed) and include this into the review, but e.g. one review comment forced a change at one specific point. Than we have all plans and maybe merge the PR earlier. This will result in some queued proposed runs, which are no longer necessary. And for these runs, we need to go into spacelift and cancel them manually to not waste resources and time.
For this purpose we’d like to have a cancel possibility, such that after a merge, all queued proposed runs are canceled.
I think your proposed solution won’t work, because it is already too late, the proposed runs are already scheduled and awaiting a free worker, so using a policy to skip those is no longer possible, right? Btw you mentioned also “you could define in a policy when a proposed run should be skipped or CANCELLED”, is it really possible to cancel a scheduled proposed run? Because this is exactly what is currently not possible and why I opened this feature request actually. The auto cancel would happen in the push policy, but this is not supported, yet, what your support engineers told us.
Best regards
Steffen
Tomato Oak
•
Feb 23
We have a similar use-case I’d describe fundamentally as follows:
We propose runs on pull requests. We track runs on merges to main
When a pull request is merged to main, the policy evaluates a tracked run off the push component of the event. But, if this run is merged before the proposed run in the pull request was ever started, we have no way to cancel that (now useless) proposed run, because it is of a different type.
As such we’d specifically love to be able to have a tracked run be able to cancel a proposed run. At present we’re only able to do this manually or via the API.
Log in to comment and vote
Comments3
Natalia Gazda
Jul 7
@Steffen Lapp
Thanks for the detailed write-up. I want to make sure we solve the right problem before we scope anything.
The way I read it, the proposed run on a PR exists to show you the plan for that change. Once you merge to main, that preview is redundant, and you're left paying twice: workers running jobs that no longer matter, plus drift notifications that the incoming tracked run is about to resolve.
Here's the direction I'd like to test with you. Instead of cross-type auto-cancel, what if you could define in a policy when a proposed run should be skipped or cancelled? For example: skip PR and drift proposed runs on a stack once a tracked run for the same change is queued. Would that cover both of your cases? Or do you also need the cancel to fire when no new run starts in that evaluation phase at all?
Rose Octopus
Jul 7
Hey @Natalia Gazda
thanks for the answer and questions.
You understood it correctly. Here is a real scenario:
We have an open PR and want to merge it, but there are pending Spacelift proposed runs. In general, we wait until all are planned (and a PR can have several runs, when a big pr was created or e.g. files in an additional project glob was changed) and include this into the review, but e.g. one review comment forced a change at one specific point. Than we have all plans and maybe merge the PR earlier. This will result in some queued proposed runs, which are no longer necessary. And for these runs, we need to go into spacelift and cancel them manually to not waste resources and time.
For this purpose we’d like to have a cancel possibility, such that after a merge, all queued proposed runs are canceled.
I think your proposed solution won’t work, because it is already too late, the proposed runs are already scheduled and awaiting a free worker, so using a policy to skip those is no longer possible, right? Btw you mentioned also “you could define in a policy when a proposed run should be skipped or CANCELLED”, is it really possible to cancel a scheduled proposed run? Because this is exactly what is currently not possible and why I opened this feature request actually. The auto cancel would happen in the push policy, but this is not supported, yet, what your support engineers told us.
Best regards
Steffen
Tomato Oak
Feb 23
We have a similar use-case I’d describe fundamentally as follows:
We
proposeruns on pull requests.We
trackruns on merges tomainWhen a pull request is merged to
main, the policy evaluates atrackedrun off thepushcomponent of the event. But, if this run is merged before theproposedrun in the pull request was ever started, we have no way to cancel that (now useless)proposedrun, because it is of a different type.As such we’d specifically love to be able to have a tracked run be able to cancel a proposed run. At present we’re only able to do this manually or via the API.