Is it possible to automatically delete old pending background tasks for the same PR?

Hi!

TL:DR: Is there a way to somehow cancel the old background task when a new task is scheduled (after merging a new commit) for the same PR?

Context: My org. uses a mono-repo.

It’s pretty typical for mono-repos to use the merge queue technique, where instead of manually merging PRs, developers mark their PRs (e.g. with a “need-to-merge” label), and the merge queue does the rest: fetches the master branch, waits for all CI builds/checkouts to go green, and (finally) merges this PR to the master.

It may take several hours before the merge queue merges the PR and during this time, it constantly merges commits from the updated master into the current PR branch. This action triggers SonarQube to scan this PR/branch over and over again (because it’s configured to scan for every PR commit).

If SonarQube already has pending tasks, it creates a new task in the background which will duplicate the old one (as shown in the picture below) which is bad because it increases the scope of background tasks and the pending time for the rest of the tasks.

Is there a way to somehow cancel the old background task when a new task is scheduled (after merging a new commit) for the same PR?

Thank you

  • SonarQube Developer Edition, Version 9.2.4 (build 50792)
  • SQ scanner 2.8.1 (NPM package: sonarqube-scanner)

Hi,

I’ve moved your thread to the Project Manager for a Day category, since this feature doesn’t exist.

Note that it is possible to manually delete a pending task, but I know that’s different that what you’re asking for: automatic duplication detection and deletion.

 
Ann

Thank you, Ann. If it’s possible, please share a link to the thread (or maybe a ticket/request ID) in order to track progress. This feature is quite important to our teams.

Thank you.

Hi,

Thanks for taking the time to share this insight.
In this case, we don’t have yet any plan to address it in the roadmap, so there’s no public reference we can provide.

I’d be happy to better understand your concern and your expectations.
Is this a strategy you are applying to your build in your pipeline, canceling the build when there’s a new commit?

Chris

Yes. There is no need to spend machine resources to continue running builds for previous commits in the same PR if the new commit was recently pushed/merged.

If you cancel the build for previous commits, are you not stopping the whole pipeline? In that case, I would expect SonarQube analysis to not even start.
Can you please tell me more about your use case?