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

Barak Korren commented on OVIRT-1867:

[~rmohr@redhat.com] the main issue I have with the concept you suggest is that it chains the code to a specific instance of the CI system.

The point of STDCI is to be a standard – you can take a compliant project and build/test it the same way on different CI systems. They way you suggest to handle secrets – it essentially chains the project to a specific CI system instance – the one that knows the right private key.

This concept makes perfect sense for PAAS providers like Travis that want to lock you into the single instance their platform…

Our view of credentials is also slightly different – instead of a developer providing his own credentials for using service X, he just asks for access for service X, and it becomes the CI system's responsibility to figure out how to provide access to that service.

Having said the above, implementing what you ask for is not difficult, so we may add this soon as an additional feature for our existing credentials support. The main challenge would be to find where to store all the private keys and provide access to the public keys. Our system doesn't really have a UI that is not linked to a specific build/test run, since so far the assumption has always been that all communication with the CI system is done via commits or comments to the SCM.

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: New Feature
         Components: Standard CI (Pipelines), STDCI DSL
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)