dependabot[bot] on maven
dependabot[bot] on maven
Bump kubernetes from 1.6.4 to 1… (compare)
Hi, I'm trying to setup an automated installation of Jenkins on Kubernetes using the
active-directory plugin. So far, it works fine and i can login, although it's stated in the documentation that it's possible to use a fallback user to login in case the AD server goes down. As I'm using JCasC to setup Jenkins on deployment using the relative helm chart, how can I on a fresh install be able to:
The main goal here is having a 0 click setup that wires up everything.
Thank you in advance for any help given.
I'm investigating using JCasC to export our jenkins server to redeploy into a new network. (We're being bought).
When I installed the plugin and ran 'view configuration', I don't see plugins obviously listed in the output.
Are they supposed to show up? Or maybe I'm not looking at the right thing?
Specifically, I'm also looking at migrating to jenkins-swarm instead of hand configuring nodes, so I installed that plug-in and rebooted and looked at JCasC output and can't spot anything related to swarm.
Hmm, I search the exported yaml and I don't find 'swarm' anywhere (matter of fact, I don't see 'plugin' anywhere), even after reboot, but maybe this is total driver error. We haven't really been keeping it up to date because we're terrified of breaking it. A few years ago, we had an engineer force an update of something and brought the server down and it took us a 'long' time to get it back up due to devops ignorance (we're an embedded firmware shop)
This lack of care and attention is what's bringing me to investigate JCasC so we don't end up in that position again...
I think the server itself is 2.223, and we have a bunch of plugin security warnings we haven't addressed for a long time. I'll try updating to latest and see if it is better.
Can someone please suggest a way to create Fall-back user programmatically when using Active Directory plugin combined with JCasC?
internalUsersDatabase: jenkinsInternalUser: admin
Ad described here https://plugins.jenkins.io/active-directory/
jenkins: authorizationStrategy: globalMatrix: permissions: - "Overall/Read:authenticated"
connectionStrategy:. When we configure it through the fronend it seems working. But we have to configure
via http POST to JENKINS_URL/reload-configuration-as-code
Reviving an old (deleted?) thread about backup/restore of build history on Jenkins controllers which of course is not handled by JCasC.
Before we "roll our own" solution in which we:
I thought I'd ask @Gaurav2Github, @jetersen, @oleg-nenashev, is there a better way in 2021, or do you still say "don't rely on Jenkins for build history"?
Managing multi-environment Jenkins clusters that need to frequently roll out new features, bugfixes, and updates from dev --> staging --> prod requires a certain level of continuity in build history when the promotions happen. I'm not saying the artifacts are important (I agree that artifacts should live elsewhere), but the historical information of what builds happened, when, and how long did they take, is essential in monitoring used by an Engineering org to make business decisions.
Related, instead of just backing up the jobs/ dir (we're using restic to make external backups from a simple hourly cron job), I'm considering using the new-ish
jenkins.model.Jenkins.buildsDir system property to separate
Without this change, since CasC and our restic restore operation would both be writing to
jobs/, I'm thinking that separating
builds/ in this way would provide some insurance against unforeseen conflicts of these two mechanisms interfering with one another.
Is it possible to change the path from which JCasC configuration YAML is loaded via the Jenkins REST interface?
The path seems to be stored in /var/jenkins_home/io.jenkins.plugins.casc.CasCGlobalConfig.xml. Updating the path via GUI updates the path in the file, but modifying the file doesn't cause the path used to be changed. Is there a process that can be triggered to re-read this file after making a change to the path in it?
Is it possible to remove access to change this setting in the GUI?
If not, then I can imagine that someone with admin privileges could make an accidental change.
I want to have Jenkins fully configurable through code. Any deviation from the desired state should be correctable via code. I don't want to have to go into the GUI to fix a mistake.
CASC_JENKINS_CONFIGin the main README