Merge groovy-cps into workflow-cps

[dwnusbaum]

This PR merges the entire history of https://github.com/cloudbees/groovy-cps into this plugin. groovy-cps is only supported in the context of Jenkins, and should only be used by workflow-cps. Keeping the library and plugin separate complicates maintenance and testing.

The only interesting changes should be in 306d1ce (moves workflow-cps into plugin module), 96735ee (merges groovy-cps into the repo), and any newer commits. Older commits are just the existing history of groovy-cps.

With this PR, workflow-cps can only be built using Java 11 or newer. The plugin will still run against Java 8, but the dgm-builder module, which is only used when building groovy-cps, uses Java compiler APIs that were modified in Java 9 and so do not work with Java 8.

TODO:

• Add workflow-cps-parent and groovy-cps to https://github.com/jenkins-infra/repository-permissions-updater
  • PR merged: Add permissions files for groovy-cps and workflow-cps-parent jenkins-infra/repository-permissions-updater#2917
• Check whether we need to add a new PCT hook to be able handle to handle workflow-cps after this change
  • PR merged: Prepare PCT for workflow-cps becoming a multi-module project plugin-compat-tester#383
• Test PCT: Update workflow-cps, antisamy-markup-formatter, and the PCT bom#1553
• Double-check that the merge looks correct
• File PR to groovy-cps to delete all existing content
  • Remove all content and update README to reference https://github.com/jenkinsci/workflow-cps-plugin/pull/612 cloudbees/groovy-cps#124
• Push old groovy-cps tags into this repo
• Archive groovy-cps

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

[dwnusbaum]

See jenkinsci/plugin-compat-tester#383 for associated PCT changes.

[dwnusbaum]

Rebuilding. (FTR, re-running a specific failed check from the left-hand sidebar on the checks page seems to work to trigger a new build, but the "re-run all checks" button from the top-right corner of the checks page does not seem to do anything, and you can only use the former if some check failed.)

[dwnusbaum]

@jglick Do you know of any other examples of multi-module projects which skip deployment of a module that are able to publish incrementals? 1b01482 makes things work, but skipping installation for groovy-cps-dgm-builder makes working with groovy-cps awkward, for example it breaks the ability to run specific tests in IDEs by default (because you always need to run tests from the parent project and run at least the package phase).

I'm not sure what other options we have. Maybe we could make groovy-cps-dgm-builder always be 1.0-SNAPSHOT so that https://github.com/jenkins-infra/pipeline-library/blob/c86c8a970564019c5708e9b10e0717c28866309d/vars/infra.groovy#L333 ignores it, and then we could remove <maven.install.skip>true</...>? Or maybe we could only activate <maven.install.skip> in a profile that is activated when env.CI=true so it only gets skipped in the CI build?

[jglick]

Do you know of any other examples of multi-module projects which skip deployment of a module that are able to publish incrementals?

plugin-compat-tester itself but I guess it does not suffer from the issue you describe.

Maybe activate the profile to skip installation when set.changelist is defined (same as produce-incrementals)?

[dwnusbaum]

I am planning on merging this once the CI build passes. Then I'll merge master into #596 and release a new version of the plugin.

I will work on merging master into existing open PRs, but I will probably not be able to get to all of them today. I'll also refile a few things from groovy-cps here today so I can archive it.