Converge upstream and suse build pipelines

[bikramnehra]

Is your feature request related to a problem? Please describe.

The purpose of both SUSE and upstream pipelines are to build and push container images from specified both releases using fissile. Ideally, the key difference among these pipelines should be SLE vs openSUSE stemcell for building images. However, lately the pipelines seem to be diverging in their implementation.

Describe the solution you'd like

The following are the areas that have been identified as cause for the divergence:

1. Secret Management:

The SUSE pipelines makes use of a private repo in order to store and populate required secrets. The secrets are rendered at the time of pipeline deployment via the use of a script. On the other hand, upstream pipelines are using lastpass for secret management.

Potential Solution:

Since the two are deployed on different infrastructure SUSE vs IBM it seems difficult to use single authentication mechanism. It would be best to abstract the authentication mechanism.

2. Deployment:

SUSE pipelines are currently relying on a script to render and generate a pipeline.yml file. The script also takes care of interpolating any config vars, secrets and any custom options. The upstream pipelines mostly rely on out of the box fly cmd line tool for pipeline deployment.

Potential Solution:

Using a custom script offers a way to add more functionality e.g: adding custom prefixes to pipeline naming, specifying target branch etc. We can also think about sub-moduling the pipeline definitions which can be wrapped in desired configs and secrets.

3. Redundancy:

There seem to be redundancy w.r.t to bosh releases being built across pipelines e.g:

https://github.com/cloudfoundry-incubator/cf-operator-ci/blob/17e39bf8f5bd54183186b4d3a71c6661ded649e2/pipelines/release-images/pipeline.yml#L2-L6

is building some of the releases which might already be taken care of in release-images-cf-deployment.

Potential Solution:

This would require close examination of both pipelines to understand overlapping releases which are being built and ways to eliminate them.

4. Missing Features:

These are some missing features in upstream pipeline:

• Ability to build multiple versions for a release.
• Ability to add new releases without the need to re-deploy/update the pipeline.
• Ability to specify releases to be built in a simple yaml structure similar to cf_deployment releases.

[bikramnehra]

Recent changes in the pipelines(specifically move to SLE15 stemcell) coupled with recent announcement about being able to now publish SLE based images on Docker Hub.

There are some areas where there is a clear distinction in value proposition of suse pipelines e.g:

• Building and publishing suse specific releases such as buildpacks.
• Being able to push to registry.suse.com.
• Secret Management.

However, for most part the underlying mechanism of build and push are the same for both which raises questions about the scope of these pipelines.

Also, there are some additional open questions such as:

• Where should the pipeline(s) source code reside/deployed so that it doesn't diverge in future?
• What registries kubecf and CAP are suppose to consume their images from?
• Should we build images in one place and push to two separate registries?
• How are we planning to tackle stemcell version updates and bumps?
• How are we planning to build multiple release versions?