[ https://ovirt-jira.atlassian.net/browse/OVIRT-1867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=35715#comment-35715 ]

Daniel Belenky commented on OVIRT-1867:

We actually have a mechanism for secrets as environmental variables in stdci. Currently, we hold the secrets in a single secret file on our Jenkins master, and engineers can request those secrets as environmental variables via *.environment.yaml. The syntax is the same as for Kubernetes:

{code:java}

• name: MY_VAR valueFrom:

  secretKeyRef:
    name: MySecret1
    value: password

{code} The example above will bind the password field from MySecret1 to $MY_VAR inside the chroot created by STDCI.

The one part which is still missing though is a common interface to allow projects to add the secrets to this file automatically.

Allow embedded secrets inside the source repo for CI

     Key: OVIRT-1867
     URL: https://ovirt-jira.atlassian.net/browse/OVIRT-1867
 Project: oVirt - virtualization made easy
         Issue Type: By-EMAIL
Reporter: Roman Mohr
Assignee: infra

In order to improve the self-service capabilities of standard-ci it is important for projects, that they can add their own secrets to projects (to reach external services, e.g. docker hub, …). Travis has a very nice system which helps engineers there: https://docs.travis-ci.com/user/encryption-keys/ Basically the CI system needs to generate a public/private key pair for every enabled git repo. The engineer simply fetches the public key via a well know URL and encrypts the secrets. Then the encrypted secret can be made part of the source repo. Before the tests are run the CI system decrypts the secrets. Than can play together pretty well with Jenkinsfiles too. Benefit:

* Less manual intervention from CI team to add secrets to jobs
* Strengthen the config-in-code thinking

— This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100077)