Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-27398

Pipeline-as-Code CredentialsProvider for a job

      There should be an analogue of FolderCredentialsProvider limited to a single Job, allowing credentials to be set on the narrowest possible scope.

      Not Workflow specific, but arguably more important for flows since they are likely to replace a whole set of freestyle projects that might otherwise have been segregated into a distinct folder.

          [JENKINS-27398] Pipeline-as-Code CredentialsProvider for a job

          Yes that is an interesting idea.

          Stephen Connolly added a comment - Yes that is an interesting idea.

          Jesse Glick added a comment -

          JENKINS-29922 is implemented, so assuming a @Symbol is defined for each credentials kind, and a credentials step is marked metaStep, you could write more simply:

          usernamePassword id: 'hipchat-login', username: 'bob', password: 'abc/def+GHI0123='
          hipchat server: …, message: …, credentialsId: 'hipchat-login'
          

          or even allow the id to be generated, and return it from the step:

          hipchat server: …, message: …, credentialsId: usernamePassword(username: 'bob', password: 'abc/def+GHI0123=')
          

          Jesse Glick added a comment - JENKINS-29922 is implemented, so assuming a @Symbol is defined for each credentials kind, and a credentials step is marked metaStep , you could write more simply: usernamePassword id: 'hipchat-login' , username: 'bob' , password: 'abc/def+GHI0123=' hipchat server: …, message: …, credentialsId: 'hipchat-login' or even allow the id to be generated, and return it from the step: hipchat server: …, message: …, credentialsId: usernamePassword(username: 'bob' , password: 'abc/def+GHI0123=' )

          Jesse Glick added a comment -

          abayer is there a variant of this that would work sanely with Declarative?

          Jesse Glick added a comment - abayer is there a variant of this that would work sanely with Declarative?

          Andrew Bayer added a comment -

          Hrm, not that I can think of off the top of my head.

          Andrew Bayer added a comment - Hrm, not that I can think of off the top of my head.

          Jesse Glick added a comment -

          Let me see, perhaps this section could be something like

          environment { 
              AWS_KEY = credentials(string('abc/def+GHI0123=')) 
          }
          steps {
              sh 'aws -key $AWS_KEY deploy' // whatever
          }
          

          Jesse Glick added a comment - Let me see, perhaps this section  could be something like environment { AWS_KEY = credentials(string( 'abc/def+GHI0123=' )) } steps { sh 'aws -key $AWS_KEY deploy' // whatever }

          Andrew Bayer added a comment -

          That might work, but I wouldn't want to make any assumptions or implementations until after JENKINS-42753 has landed, given how drastically it changes parsing.

          Andrew Bayer added a comment - That might work, but I wouldn't want to make any assumptions or implementations until after JENKINS-42753 has landed, given how drastically it changes parsing.

          Jesse Glick added a comment -

          Sure, I just meant to draw a sketch of what it might look like from a user perspective, not a concrete syntax.

          Jesse Glick added a comment - Sure, I just meant to draw a sketch of what it might look like from a user perspective, not a concrete syntax.

          R. Tyler Croy added a comment -

          I would love for this work to exist, so I could ditch my experimental inline-pipeline-secrets work.

          The key thing from a user perspective (IMHO), is that somebody who is authorized to modify the Jenkinsfile should be able to easily create the ciphertext (or Credential, I don't care what it is), which could be written into the Jenkinsfile.

          This would be conceptually similar to how Travis CI allows creating encrypted tokens per-job.

          R. Tyler Croy added a comment - I would love for this work to exist, so I could ditch my experimental inline-pipeline-secrets work . The key thing from a user perspective (IMHO), is that somebody who is authorized to modify the Jenkinsfile should be able to easily create the ciphertext (or Credential, I don't care what it is), which could be written into the Jenkinsfile . This would be conceptually similar to how Travis CI allows creating encrypted tokens per-job.

          Jesse Glick added a comment -

          rtyler yes that is the idea exactly.

          Jesse Glick added a comment - rtyler yes that is the idea exactly.

          R. Tyler Croy added a comment -

          Then yes please, i'll take eleventy of those immediately thanks.

          R. Tyler Croy added a comment - Then yes please, i'll take eleventy of those immediately thanks.

            jglick Jesse Glick
            jglick Jesse Glick
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated: