Add quickstarter pipeline

[michaelsauter]

Implements a new pipeline that can be used to provision quickstarters.

It uses the same style as the new "component pipeline", with some simplifications. For now, this pipeline has only been used for the Go quickstarter (opendevstack/ods-quickstarters#222). I'll convert the other ones after this PR is merged .. in the process, I might need to do some minor adjustments to the pipeline.

To visualise what a new Jenkinsfile looks like, here's the one from Go (updated):

def odsGitRef = env.ODS_GIT_REF ?: 'production'
def odsImageTag = env.ODS_IMAGE_TAG ?: 'latest'
library("ods-jenkins-shared-library@${odsGitRef}")

odsQuickstarterPipeline(
  imageStreamTag: "cd/jenkins-slave-golang:${odsImageTag}",
) { context ->

  odsQuickstarterStageCopyFiles(context)

  stage('Write go.mod') {
    dir(context.targetDir) {
      sh "echo 'module example.com/${context.projectId}/${context.componentId}' > go.mod"
      sh "echo '' >> go.mod"
      sh "echo 'go 1.12' >> go.mod"
    }
  }

  odsQuickstarterStageCreateOpenShiftResources(
    context,
    [directory: 'common/ocp-config/component-environment']
  )

  odsQuickstarterStageRenderJenkinsfile(context)

  odsQuickstarterStageRenderSonarProperties(context)
}

Some observations:

• I noticed that the way I implemented it, we basically don't need the IContext as Context is just data access. Thoughts on this?
• There's some boilerplate around the image (dockerRegistry/odsImageTag). I guess we can get rid of it, but might be a bit of magic
• The quickstarterId is required right now - that could also be read from the pipeline itself - it has jenkinsfilePath: "be-golang-plain/Jenkinsfile" set. I might default to that, and allow people to override?
• Setting up OpenShift resources will likely be similar across most quickstarters. Maybe we can simplify that too - but unsure what the right level of abstraction is. Right now I'm leaving that for later ...

[clemensutschig]

I like it - I am wondering if we should not rename the context thing .. we have then 2* IContext, just in 3 different pacakges.

[michaelsauter]

@oalyman @renedupont I've done a few more changes to make it even easier to author quickstarters. Could you provide feedback too? Thx!

[michaelsauter]

@clemensutschig @henrjk @oalyman Good to merge this? I'd love to proceed with converting the quickstarters. If you are OK with the "interface" - so the way that quickstarter Jenkinsfiles are written using this PR, then I suggest to merge this, and we can open up cleanup / enhancement issues.

[henrjk]

This looks very neat.

I am torn on whether I'd rather see unique type names unique so that quickstarter names cannot be confused with component names.
On the other hand the qs classes could presumably also be in their own shared library.

Sorry for the ramblings.

[henrjk]

What is keeping you from removing IContext and adding potential docs right here?

[michaelsauter]

@henrjk With IContext I can use the type in the code while exchanging the implementation in the tests.

[michaelsauter]

@henrjk Thanks!

Actually I really want to have this as a single library, but I have failed to outline the reasoning:

• one repo is easier to manage then multiple (in terms of releases, branches, issues ...)
• there are many things that can be shared between the libraries, such as interaction with OpenShift (services)
• having one repo enforces more similarity (in terms of testing approach, dependencies used etc.) which makes it easier for people to work across libraries