There is a just a lot of configuration files in this repository that makes it very hard for anyone new to understand what is going on. Adding some basic docs (like apps vs packages, what is being deployed etc) will also help.

A few things I can think of are,

1. How are the yaml files applied? Are all of them used? Where is the code for it?
2. What is apps vs packages?
3. What is the pom.xml, release.groovy and jenkins file really doing there? Are we shipping all the files as a maven package and then downloading it back to osio while being deployed?
4. Can we remove all the maven bits from here? Is it really necessary?
5. Is apps/jenkins-test used at all?

cc: @aslakknutsen

In conversation with Gabe Montero ([email protected]) doing alot of ci/cd on openshift.com he spotted we were using groovy.use.classvalue and he commented with these findings:

Some basic internet searching took me down an interesting path:

• guidance during an old release upgrade: https://jenkins.io/doc/upgrade-guide/2.7/
• which referenced a groovy issue https://issues.apache.org/jira/browse/GROOVY-7591
• which referenced a jdk issue https://bugs.openjdk.java.net/browse/JDK-8136353
• which circled back to a groovy issue https://issues.apache.org/jira/browse/GROOVY-7683 which >presumably resolved the memory leak (v2.4.8 of groovy ...v.2.89.4 of jenkins as v2.4.11)
• and in fact the https://jenkins.io/doc/upgrade-guide/2.73/ says you no longer need this workaround

And the kicker ... this support article from cloudbees from Jan 2018 strongly advises to no longer use >this setting ... saying you could introduce a memory leak

So perhaps something to monitor, but I WILL NOT be putting this setting on by default in the openshift >jenkins image.

I'd also suggest that unless openshift.io is aware of something more recent, etc. that contradicts that >Jan 2018 article, you
should probably remove that setting as well.

The support article mentioned I assume is https://support.cloudbees.com/hc/en-us/articles/115001505172-Jenkins-hangs-due-to-Groovy-ClassInfo-deadlock which contains this msg:

"(Deprecated) Workaround

JENKINS-43197 mentions a workaround that is to add the system property -Dgroovy.use.classvalue=true on Jenkins startup to re-enable ClassValue. This is deprecated and we strongly advise to not do this. ClassValue was disabled by default to solve major memory leaks - see GROOVY-7591. Enabling ClassValue would replace a groovy memory leak by another one."

I haven't checked the impact but thought it was worth being aware of it if looking into optimizations/cleanup.

By default, the Jenkins base URL for the build log is determined via the OpenShift route of the Jenkins service.
With the introduction of Jenkins proxy/idler, we have to update log base URL with Jenkins proxy one.
To override and configure this base URL, an environment variable JENKINS_ROOT_URL can be set through openshift deployment-config yaml

Fix for: fabric8io/jenkins-sync-plugin#11

Right now, if a PR build is going on and if we push a commit to PR then we need to cancel the previous build and start a new build.

Needs changes in Jenkins config map

Relevant issue on osio is openshiftio/openshift.io#3862