"DRY violations" with the TsscPipeline CR: Image Pushing/Signing

[hatmarch]

There are some "don't repeat yourself" / brittle double coding issues when defining a software pipeline (for jenkins, but this probably applies to any pipeline).

Consider the attached TsscPipeline resource. As coded it will run into two issues with image signing due to a series of issues where the pipeline thinks the image repo is called ref-quarkus-mvn-jenkins-std. Since it doesn't exist, it creates a private repo (quay default) and the next signing step fails b/c it expects the repo to be public.

BUG: There is a public repo created by the operator, but it names that repo based on the appname field of the CR

With Ploigos operator 0.2.2 and Ploigos jenkins library 0.17.0

[hatmarch]

tsscpipeline-tsscpipeline-jenkins-issue.yaml.zip

[hatmarch]

One way to solve this is via the PSR config arguments (see image for where they get set). The platform currently creates a configmap of these that help the PSR find things that are specific (e.g. cluster local) to what the platform operator setup. What if we also allowed the Pipeline half of the operator create another config map that would include the values specific to it (e.g. name of image registry) and expose it to the Jenkins/Tekton pipeline in that way.

One downside is now you could have config coming from 3 places (platform CR, pipeline CR, and code repo) and you would need to determine prioritization between these (probably repo > pipeline > platform).

[hatmarch]

One problem with that approach is that it gets pretty confusing and error prone to the end user. If we had the ability to overhaul the system, it might be better to allow there to be only 1 config.yml (in the REPO) but allow that config.yml to accept token replacement within it (e.g. { platform-nexus-host } or { pipeline-image-repo-host }) like an ansible template (.j2) that get resolved by the ploigos-jenkins-library on pipeline kickoff