timja on master
JENKINS-67371 Explicit the trus… (compare)
timja on master
Add log recorders demo / test (… (compare)
securityRealm:
local:
allowsSignup: true
jenkins:
securityRealm:
ldap:
cache:
size: 100
ttl: 30
configurations:
- groupSearchBase: "OU=Jenkins,OU=Security Groups,OU=DevOps"
groupSearchFilter: "(&(cn={0})(objectclass=group))"
ignoreIfUnavailable: true
inhibitInferRootDN: false
managerDN: "jenkinsldap"
managerPasswordSecret: "${LDAP_PASSWORD}"
rootDN: "dc=company,dc=io"
server: "ldaps://ldap.company.io:3269"
userSearch: "sAMAccountName={0}"
disableMailAddressResolver: false
groupIdStrategy: "caseInsensitive"
userIdStrategy: "caseInsensitive"
GitLFSPull
seems to be omitted in the Jenkins job dsl: https://jenkinsci.github.io/job-dsl-plugin/#path/job-scm-git-extensions
Hi everyone! we are using casc for our new jenkins. We have a very old dated jenkins in our company and we are moving as much as we can to have things in code.
For this we use casc with a dockerfile and job-dsl with pipelines for job configurations
Now we are facing how we will deploy this system. The main idea was to start a fresh docker on each deploy since each docker version will have different configurations.
We face 2 "problems" here:
Build history and logs
we loose all of this, this can be workaround with some metrics (datadog in our case) since regarding history we care more about when something started failling and not the logs per se.
API keys
We switch from one docker to another during deploy. For the user this is a weird experience.
So we want to notify the user X given time before the change. For this, we tell Jenkins A to stop running new jobs. When there are no jobs running anymore we switch to the other version.
In order to do this, we use the API and a user token. The problem is that we use LDAP plugin to make auth. This means we need a way to generate the user token in the first place. We tried different approaches but all of them look really weird...
How would you approach this last point?
Also interested in how other people is deploying CASC
ok! that last part is the one that i didn't know! thanks @timja!
Regarding the API, no, we can't use user:password for auth with ldap. That's why we need the api token, but there's no way to generate it unless we manually create it or a job does it for us (if it's possible)
That last approach is the one we are testing, but feels very hacky