Release automation - Push Helm Chart to helm-charts repo

[sigalsax]

Our pipeline currently builds a helm chart as part of the build pipeline. We now want to be able to push packaged helm chart to the helm-charts repository as part of our version release

ToDo

• Challenge design and maybe create a new one after new limitations. See thread: https://conjurhq.slack.com/archives/C8BNMU0KV/p1603715930420900
• Implement and generalize the action in helm-charts to be reused by other repos/pipelines/etc
• Trigger the action from publish.sh
• Provide guidelines for how to use GH actions in Conjur

Done

• Talk to infra about how to automate the pushing of our Jenkins artifacts to another repo (helm-chart)
• Create POC to validate action works. See here

Help resources

• http://blog.marcnuri.com/triggering-github-actions-across-different-repositories/
• https://github.com/conjurinc/cloudfoundry-conjur-tile/blob/master/.github/workflows/draft-release.yml

[sigalsax]

Progress

POC repo: https://github.com/sigalsax/poc-github-actions

Flow

1. On successful build, the Release stage will run ./bin/publish
2. When [ "$GIT_DESCRIPTION" = "v${VERSION}" ], an HTTP request will be sent from Jenkins to trigger an event in helm-charts repo
3. The action in helm-charts repo will (DONE)
   1. Clone the SP4Ks Repo
   2. Package the helm chart
   3. Commit the Helm chart tgz to a helm-chart branch
   4. Create PR in helm-charts

HTTP request

FLOW

Notes:
- The access token will be fetched from summon beforehand
- In request ref will be ?? and the secrets-provider-ref will be an object {“secrets-provider-ref”: ?? } with info to help generalize the event.
Ex:

{
  "ref": <ref>,
  "project-ref" : [
     {
       "version": <version>,
       "full_repository_name" : <full_repostiory_name>,
       "helm_package_path": <helm_package_path>,
       "pr_assignee": <pr_assignee>
     }
  ]
}

version: -> 1.1.0
full_repository_name -> cyberark/secrets-provider-for-k8s
helm_package_path -> secrets-provider-for-k8s/helm/secrets-provider
pr_assignee -> sigalsax

The actual action will need to accept these inputs under input: in the action

Change repository_dispatch to workflow_dispatch

[sigalsax]

@izgeri suggested update design
https://conjurhq.slack.com/archives/C8BNMU0KV/p1603716511421800?thread_ts=1603083343.320200&cid=C8BNMU0KV

1. secrets provider add the helm chart .tgz to its github releases, like we upload ZIPs for the buildpack
2. the consumer repo (eg cyberark/helm-charts), if it has a way of being alerted when a new tag is available in secrets-provider, can kick off a workflow to auto-open a PR adding the release artifact.
3. the helm-charts workflow can grab the artifact from the SP gh release like how we grab the buildpack ZIP when we build the PCF tile
4. the helm-charts workflow can open a PR against itself, using its own github token, like we do in the OSS suite repo when we draft a new gh release (tag-triggered) and when we open a PR to save the suite YAML

[sigalsax]

There have been some limitations that were introduced with current design.

See discussions here: https://conjurhq.slack.com/archives/C8BNMU0KV/p1603715930420900

This might require a new decision as Geri suggests where we grab the packaged helm chart artifact from releases from another workflow (helm-chart)

Geri's design: https://conjurhq.slack.com/archives/C8BNMU0KV/p1603083343320200