Hobo GitOps!

[Cervator]

What does this PR do?

Introduces a Hobo-rific approach to GitOps: Operations by pull request, or really just one step on the way there, namely putting more things under Git control that's specific to some sort of workflow. Goes with:

• https://github.com/Cervator/GitOpsManifest - a tiny amount of configuration meant to help define a Jenkins' uniqueness via Git. An eventual goal is to use Jenkins CasC-compatible YAML instead.
• https://github.com/Cervator/GitOpsUtilityJobs - a few DSL-based jobs that do things to Jenkins itself based on config retrieved from the manifest. Allows run-time application of changes rather than rely on restarting Jenkins to pick up changes from init scripts or CasC files, yet by using the same config.

This is still one step away from proper GitOps in applying changes to a live environment for some software project - however - it also kinda achieves that since this sort of Hobo GitOps is meant to help maintain the GitOps itself as such an expression of organized control.

There is a chain of seed jobs included that ultimately point at a pretend-team target Job DSL repo that normally would be the GitOps magic meant to help promote an actual application being managed this way. For the moment the ultimate seed job is just pointed at https://github.com/Cervator/job-dsl-gradle-example which is my fork of a nice but unrelated set of more advanced Job DSL techniques, shrunken down a bit.

As such the main thing missing is an actual pretend-app being maintained by this project. Secondly I'd like to include more hooks for using this to entangle multiple such projects, in separate Jenkins Masters if necessary.

Why did you take this approach?

GitOps is cool. Version control all the things!

Probably this could be hard to make sense of in its current shape without further guidance. It is a watered down demo version of what I've been working on professionally for some time now, and may demo at a Jenkins Days event coming to a town near you ...

Flexibility has been a core concern here, with the idea being that actual serviced teams could arrive with a variety of needs and technology and preferences and so on. They might even leave again and come back depending on management directives and so on. Hobos, really, in the world of shiny but occasionally rigid tools or other requirements that may have far more stringent constraints than some teams may be ready to adopt, such as a full on Kubernetes implementation.

The fancy tools may still be in use by some teams, where this process then just ceases after plugging in some details via GitOps that "Thing X is supposed to look like Y", leaving it up to a next layering of tools to make that happen in a given environment.

Contribution checklist

• THERE ARE NO UNENCRYPTED SECRETS HERE
• The branch is named something meaningful
• [kinda] The branch is rebased off of current master
• There is a single commit (or very few smaller ones) with a Good commit message that includes the issue if there was one
• You have tested this locally yourself

A picture of a cute animal (optional)