feat: separate updatecli stages to their own pipeline #2817
Conversation
lemeurherve
changed the title
There was a problem hiding this comment.
jenkins-infra/helpdesk#2778 specified a top-level Job of type "GitHub organization scanning" that would search for each Jenkinsfile_updatecli for each branch of each repository.
I understand that you are creating a job alongside the current "kubernetes-management": is there a particular reason for this choice?
note that I'm not against your proposal, neither in favor, it's a neutral question to be sure that I can catch up.
Also, my question is motivated because since we changed from (gh-org job) to (folder of multibranches jobs), there might be a lot of good reasons
… job-dsl chart for a 'organization-scanning' kind
|
Changed to a top level folder job with one children for now. We'll adapt the jenkins-jobs chart to allow specifying a job of kind: folder with specific jenkinsfilePath, see jenkins-infra/helm-charts#105 |
This reverts commit 597c733.
…2817) * feat: separate updatecli to its own pipeline Ref: jenkins-infra/helpdesk#2778 * add updatecli job for kubernetes-management on infra.ci * remove redundant 'Management' * clean Jenkinsfile_updatecli * remove unused do token credential for kubernetes-management-updatecli * update updatecli manifest * set a top folder with one children instead for now until we adapt the job-dsl chart for a 'organization-scanning' kind Co-authored-by: Damien Duportal <[email protected]>
Ref: jenkins-infra/helpdesk#2778