@hak33m16: thats specifically the jobdsl plugin, which has lots of docs. I'm not sure anyone here is experts at jobdsl. Also you could just have a jenkinsfile that uses a global library so you the logic is external to the job being created
@halkeye:g4v.dev Do you think the behavior I posted above coming from the jobdsl plugin? I can't seem to find any docs from them describing it
Would anybody here happen to know if seed jobs require a reload of all jobs on Jenkins when changes are found? Specifically referring to the example here: https://github.com/jenkinsci/configuration-as-code-plugin/blob/master/docs/seed-jobs.md
Just asking, because currently I use the Jenkins helm chart to modify my jobs, which is inconvenient because any changes to the yaml (e.g. groovy code for the jobs under jobs: - script:) requires a full restart of master. This makes it very difficult to manage updating jobs while people are using the instance, and is causing us to resort to a model of modification where we:
- modify jobs in the UI
- translate that back to groovy code
- put up a PR for the changes and hope there aren't any mistakes we'll find next time we have to redeploy
@timja I'm not sure, I could be doing something wrong, but modifying the groovy code in the yaml causes the Jenkins master to restart when I helm deploy my changes. I'm using v2.6.5 of the Jenkins chart, specifically referring to modifying this entry in my values: https://github.com/jenkinsci/helm-charts/blob/jenkins-2.6.5/charts/jenkins/values.yaml#L267
I'm thinking it might be a limitation of modifying jobs through there, which is why I was asking if there were any similar limitations to the seed jobs approach. From what I'm seeing online, it looks like going that route will silently update the JCasC/JobDSL config in the background, and I'll have to "Reload existing configuration" from the UI still, if this page is correct: https://opensource.com/article/20/4/jcasc-jenkins -- which I believe will still cause a moment of downtime/unavailability, right?
@halkeye:g4v.dev Thanks for the clarification, I wasn't exactly sure why it was doing that
I'm still left with the question, though, is there a way to modify jobs using JCasC/JobDSL that doesn't require intermittent downtime of my Jenkins instance? Using "Reload existing configuration" will cause intermittent downtime even when going with the seed job approach, correct? I'm just trying to get to a state where I can modify a production instance without that reload/restart, which is the state that I was in previously when the jobs were stored as .xml files and modified through the UI
Really appreciate all the help so far btw guys
libraries:
- includeInChangesets: false
name: "jenkins-pipeline-lib"
retriever:
modernSCM:
scm:
git:
credentialsId:
It seems that the following configuration does not work, can someone help:
credentials:
system:
domainCredentials:
- string:
scope: GLOBAL
id: "my-token"
secret: "kubernetes.io/serviceaccount/token"
description: "ServiceAccountToken"
3 replies
Does anybody know if there's a channel for the JobDSL plugin? I can't seem to get this example working properly with my jobs: https://github.com/sheehan/job-dsl-gradle-example
Basically, it fails to load almost every single plugin I specify, showing errors like:
11.442 [id=33] SEVERE jenkins.InitReactorRunner$1#onTaskFailed: Failed Loading plugin Pipeline v2.6 (workflow-aggregator) java.io.IOException: Failed to load: Pipeline (2.6) - Failed to load: Lockable Resources plugin (2.10)
However, for the jobDsl and jenkinsVersion I specified, I absolutely already have an instance standing up using those versions that loads the plugins no problem
2 replies
In the UI page of https://<my-jenkins-url>/configuration-as-code/, there's a "Path or URL" field, and an "Apply new configuration" button that's supposed to pull the new configuration from this location. Is there any way to do this against a repository that requires authentication?
Follow up on this, I ended up in a position where the /raw endpoint for our BB server is behind 2FA, and there's not really any easy way for us to expose it currently. So, my next approach:
- Create a job that gets triggered on pushes to the master branch of the repo that our JCasC yaml is located in
- When triggered, it'll use the method describe here: https://stackoverflow.com/questions/54770969/jenkins-configuration-as-code-programmatically-reload-configuration-from-file to emulate the same thing the "Apply new configuration" button does at that URL
Which leaves me with the question: when I check out the repo, can I just call this method: https://javadoc.jenkins.io/plugin/configuration-as-code/io/jenkins/plugins/casc/ConfigurationAsCode.html#configure(java.lang.String...) with the argument being the location on disk (e.g. the current builds workspace) to replace the config from? It doesn't seem like there are any docs on the Java way to do it
Or is it recommended that I try to use the reload REST endpoint from inside the Jenkins instance itself instead? If so, could somebody point me to the docs for that?
JENKINS_URL/reload-configuration-as-code method
19 replies
what is the fastest way to convert existing jenkins to configuration as code?
have jenkins with lots of configuration and structure that i want to move to be all in code but when tried to move some of it , see that its not straight forward and will take some effort, is there any fast way for this?
as i'm using helm and want all the configuration to be external of the docker itself,
is there alternative way to expose the jenkins.yaml
and not as mentioned in documentation inside the dockerFile?
COPY jenkins-casc.yaml /usr/local/jenkins-casc.yaml
tell the jenkins config-as-code plugin where to find the yaml file
ENV CASC_JENKINS_CONFIG /usr/local/jenkins-casc.yaml
Would anybody be able to point me in the right direction of getting this working in a scripted pipeline? https://github.com/jenkinsci/configuration-as-code-plugin/issues/1227#issuecomment-566470115
I'm trying to run the reload in the same job that I'm doing some other operations, but I run into the stacktrace described at the root of that issue. No amount of googling 'systemGroovyCommand' or other terms is helping me figure out how to run code in the Jenkins sandbox unfortunately, which I assume to be the only workaround?
What's even weirder is that the JCasC reload triggered by executing that Groovy code in my pipeline actually seems to work, it's the Job reload that fails (which I don't even really want anyways...)
My pipeline code for reference:
node('master') {
stage('Checkout') {
checkout scm
}
stage('Replace Config') {
sh 'ls /var/jenkins_home/casc_configs/ -lAh'
sh 'ls ./values/jenkins -lAh'
sh 'cp ./values/jenkins/jcasc-prod.yaml /var/jenkins_home/casc_configs/jenkins.yaml'
io.jenkins.plugins.casc.ConfigurationAsCode.get().configure()
}
}