Polling can be done on the controller, without any workspace

[Kalmalyzer]

We have recently begun the Plastic SCM plugin together with on-demand provisioned agents via the Google Compute Engine plugin. This works well, except that activating the "Poll SCM" feature results in errors. This is because the Plastic SCM plugin's polling currently is implemented to require a workspace. Polling also remembers which agent was used for the previous build, and tries to re-use that agent. This does not work well with on-demand provisioned agents.

This PR moves polling over to the controller instead.

Good:

• Polling no longer relies on agents being present & available, and works well with plugins such as google-compute-engine-plugin.

Bad:

• It requires cm to be present on the controller, and plastic to be configured for the user that runs the controller. This is a breaking change for other people that already use the plugin today.
• It will place a slightly higher load on the controller (particularly when there are lots of changes - the cm invocation results in many MB of XML output, which then needs to be parsed etc, but then again, that data doesn't need to be transferred over the network).
• It will create temp files (those XML files) within Jenkins' root filesystem instead of on agents' filesystems; these files are short-lived, but can be >100MB in size.

The P4 plugin has introduced polling on the master as an option.

The Git plugin has a "fast remote polling" feature, and can poll on the controller for single-branch workspaces, but not for multibranch scenarios AIUI.

I have tested this implementation on a setup with the controller on Kubernetes and agents provisioned via the GCE plugin. Both were running Linux at the time. I haven't tested with other OSes.

What do you think - do you approve of this in its current form? Would you prefer to have this to be opt-in? If so, would you prefer a per-job or a plugin-wide setting?

• [x] Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• [x] Ensure that the pull request title represents the desired changelog entry
• [x] Please describe what you did
• [x] Link to relevant issues in GitHub or Jira
• [x] Link to relevant pull requests, esp. upstream and downstream changes
• [x] Ensure you have provided tests - that demonstrates feature works or fixes the issue

[Kalmalyzer]

Breaking existing installations is not a good idea. I have made this opt-in per-project.

One thing to note, if/when testing this: when you have a pipeline job, then the polling settings are taken from the last build performed. If you change configuration (either selector, or Poll on controller) for an existing job, then you need to trigger a build once before the changes will take effect for polling. Restarting Jenkins makes no difference. To confirm this, add some debug prints to the PlasticSCM constructor + PlasticSCM.requiresWorkspaceForPolling(). It's a built-in Jenkins behavior.

I have tested the new version both with freestyle and pipeline jobs. Linux controller + linux agent. I have focused on testing the new "poll on controller" flow, not the prior "poll on agent" flow.

This looks good to me now. What do you think?

[mig42]

Hi @Kalmalyzer !

Thank you so much for your contribution. I think your proposal is really interesting and provides value to all users of our plugin. I like that you decided to make it opt-in to avoid issues with existing setups.

There are two things I'd like to address before merging this PR:

• We need to test it using a Windows controller, to verify that it works as expected in that platform too
• We need to document this new feature. Could you add some extra contents to the README.md?

Thanks!

[Kalmalyzer]

I have tested this with a Windwos controller and confirmed that it works.

Also, I have updated the first screenshot in README.md + written a text section on the "Poll on controller" setting.

Will this do?

[mig42]

Yes, it looks good to me! Thank you for your contribution! 😄