Cancelling tasks while in the queue

[rri...@gmail.com]

Hello.

I am writing a plugin for cancelling tasks which are in the queue on a few conditions.

One of this conditions is:

* The task should be cancelled previously to get an executor for build if others conditions are true.

The final goal is cancelling the task if there was not scm changes since last build (if it was sucessfully).

I've just write a QueueListener extension, but I didn't sucessfuly on cancel a job.

This is the code:

@Extension

public class CancelJobPlugin

extends QueueListener {

    private final static Logger LOGGER = Logger.getLogger(CancelJobPlugin.class.getName());

    @Override

    public void onLeaveBuildable( final BuildableItem bi ) {

        final Queue queue = Jenkins.getInstance().getQueue();

        try {
            // This doesn't work
            queue.cancel( bi.task );
            // This doesn't work

            queue.doCancelItem( bi.getId() );

            LOGGER.info( "CANCELLED..." );

        } catch ( final IOException | ServletException cause ) {

            LOGGER.log( Level.SEVERE, "ERROR CANCELLING...", cause );

        }

    }

}

Well, I don't know why doesn't work. The 'CANCELLED' message if showed, but the task gets an executor and the build starts.

I tried too with the onLeft method.

How can I cancel a task previously to get an executor?

May be with another extension?

Thank you for your help.

[Jesse Glick]

On Wed, Dec 19, 2018 at 12:44 PM <rri...@gmail.com> wrote:
> I am writing a plugin for cancelling tasks which are in the queue on a few conditions.

https://javadoc.jenkins.io/hudson/model/Queue.QueueDecisionHandler.html#shouldSchedule-hudson.model.Queue.Task-java.util.List-

sounds like the more appropriate extension point, but

> The final goal is cancelling the task if there was not scm changes since last build

this is odd since that is the usual behavior of Jenkins under common
configurations (`SCMTrigger`). Why would a task have been added to the
queue to begin with if there were no SCM changes?

[rri...@gmail.com]

Three years ago I wrote a small modification to the MultiJobPlugin.

That modification avoid builds a job under certain conditions, one of them is the absence of scm changes.

But that code is available only to Multijobs, and I would like to provide that functionality to more job types.

In my company we have several projects developed by providers.

Each project is divided into subprojects, and it is necesary build subprojects in a ordered sequence, but only when it is necessary, and in a predectible schedule, not when SCM changes are detected.

So from 10:00am until 08:00pm every two hours Jenkins launch "Continuous Buildings": for every project exists a Job that knows the ordered sequence of subprojects, and with the help of the Multijob project and the "Build only if scm changed" subprojects are build only when necessary (workspace is empty, or last build was not stable, or scm contains changes...).

At 11:00pm Jenkins launch Nightly buildings, that are similar to Continuous Buildings, but we analyze the code quality with SonarQube and the vulnerabilities with OWASP plugin, in the same ordered sequence.

The logic for deciding if the job (corresponding to a subproject) should be builded is inside the Multijob plugin, so this feature is restricted to it.

I want to extract that logic to provide a plugin for providing that functionality in FreeStyle Jobs, Maven Jobs and in a future in Pipeline Jobs (maybe...).

That is the reason for not using the SCM Trigger feature.

May be I am wrong, but this strategy works very well on my company in small projects (less than 20.000 LOC) and medium projects (about 800.000 LOC), with one or more development branches.

Jesse, thank you for your help.

[Jesse Glick]

On Wed, Dec 19, 2018 at 2:51 PM <rri...@gmail.com> wrote:
> it is necesary build subprojects in a ordered sequence, but only when it is necessary, and in a predectible schedule, not when SCM changes are detected.

But this is just what `SCMTrigger` does, if you give it a polling
schedule (and do not register webhooks). Maybe I am missing something.
Anyway if you want slightly customized behavior, perhaps you just want
to write a new `Trigger` implementation.

> in a future in Pipeline Jobs

Note that in Pipeline you can also inspect `currentBuild.changeSets`
in your script and decline to do any real work if it is empty (just
`return` early).