You should be able to specify secrets for builds with jenkinsPipelineStrategy

[tnozicka]

You should be able to specify secrets for builds with jenkinsPipelineStrategy same way as environment variables.

This seems to be essential when trying to do cross-cluster deployments; you need to inject secrets to your pipeline - like token for authentication to remote cluster.

@bparees

[bparees]

trello'd https://trello.com/c/SHuzb0cL

[bparees]

trello'd https://trello.com/c/SHuzb0cL

[bparees]

@tnozicka we discussed this card today and it seems like you can work around this by using oc commands within your Jenkinsfile to grab the secrets you need, true?

[bparees]

@tnozicka we discussed this card today and it seems like you can work around this by using oc commands within your Jenkinsfile to grab the secrets you need, true?

[tnozicka]

@bparees I think you are right with the workaround.

You can still do a bit more by having a proper support for secrets like:

• Switch between them without modifying the Jenkinsfile (which you may not have under your control in case of integration solutions using OpenShift API)
• Modifications require committing code (Jenkinsfile) to development repository
• Say administrator wants to try to switch the pipeline to use different secrets (configuration) and he has to delete/rename/change the existing secret that may be also referenced by other pipelines or objects because it can be only controlled by editing the name in Jenkinsfile which requires committing code to the development repository.
  Sure you could hack it once more by wrapping all secrets by environment variable, but that's gonna get nasty.
  Modifying pipeline BC, changing secret's name and keeping the same destinationDir seem much easier.
• Regular builds supports specifying build secrets AFAIK

I would consider this nice to have, but not critical.

[tnozicka]

@bparees I think you are right with the workaround.

You can still do a bit more by having a proper support for secrets like:

• Switch between them without modifying the Jenkinsfile (which you may not have under your control in case of integration solutions using OpenShift API)
• Modifications require committing code (Jenkinsfile) to development repository
• Say administrator wants to try to switch the pipeline to use different secrets (configuration) and he has to delete/rename/change the existing secret that may be also referenced by other pipelines or objects because it can be only controlled by editing the name in Jenkinsfile which requires committing code to the development repository.
  Sure you could hack it once more by wrapping all secrets by environment variable, but that's gonna get nasty.
  Modifying pipeline BC, changing secret's name and keeping the same destinationDir seem much easier.
• Regular builds supports specifying build secrets AFAIK

I would consider this nice to have, but not critical.