Depend on resource after "put" with manual interaction


#1

Hi,

sorry for the weird title, not sure how to put that properly.

Here’s my problem:
I am building a release tool that allows people to approve a release. In an ideal world, the workflow is this

  1. Concourse CI runs for the master branch
  2. Job “request release approval” gets called, does a “put” to custom resource(“version”)
  3. People approve and release the version on the external tool
  4. the pipeline continues with the deployment, depending on the previous “version” that was put.

Naturally, there is a manual step at 3. I have implemented the in script for my resource to only query for approved releases (?released=true). This breaks when the “put” does an implicit get, because the version is not released yet (query returns no results). I have tried using get_params to also query pending releases. This results in the pipeline continueing, but immediately after the “put”. I want to wait until the version has been released.

My next idea is to split the pipeline up and remove the passed option from the pipeline, but that makes it visually harder to understand.

Is there anything else I could try?

my pipeline

resource_types:
- name: release-tool
  type: docker-image
  source:
    repository: ...
- name: meta
  type: docker-image
  source:
    repository: swce/metadata-resource

resources:
- name: metadata
  type: meta

- name: version
  type: release-tool
  source:
    api_key: ...
    team_url: ...

jobs:
- name: request new release
  plan:
  - get: metadata
  - task: construct release payload
    ...
  - put: version
    params:
      payload_path: release-request/payload
    get_params:
      fetch_pending: true

- name: show release
  plan:
  - get: version
    trigger: true
    passed: [request new release]
  - task: construct release payload
    ...

Kind regards,


#2

Since releasing is a manual process anyway, how about insert a job 3.5 that says “verify release”, depends on passed “request new release” but is not triggering automatically on new version. So the process looks like

  1. Concourse CI runs for the master branch
  2. Job “request release approval” gets called, does a “put” to custom resource(“version”)
  3. People approve and release the version on the external tool
  4. People trigger “verify release” job in concourse to mark the release completed
  5. the pipeline continues with the deployment, depending on the previous “version” that was put.

Alternatively you may find some inspiration in https://github.com/Meshcloud/gate-resource which we use at meshcloud to model our (somewhat more complicated :wink: release process to different environments.