secrets-provider-for-k8s icon indicating copy to clipboard operation
secrets-provider-for-k8s copied to clipboard

Release automation - Push Helm Chart to helm-charts repo

Open sigalsax opened this issue 5 years ago • 3 comments
trafficstars

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

  • [x] Talk to infra about how to automate the pushing of our Jenkins artifacts to another repo (helm-chart)
  • [x] 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 avatar Oct 19 '20 07:10 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 Screen Shot 2020-10-19 at 12.29.10 PM.png

FLOW Screen Shot 2020-10-19 at 12.21.13 PM.png

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 avatar Oct 19 '20 13:10 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 avatar Oct 26 '20 13:10 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

sigalsax avatar Nov 01 '20 07:11 sigalsax