pivotal-cf/concourse-pipeline-steamroller

Name: concourse-pipeline-steamroller

Owner: Pivotal Cloud Foundry

Description: null

Created: 2017-11-17 19:10:52.0

Updated: 2018-05-13 03:59:20.0

Pushed: 2017-11-17 19:42:27.0

Homepage: null

Size: 11

Language: Go

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

concourse-pipeline-steamroller

Convert this:

:
me: my-job
an:
get: some-resource
task: some-task
file: some-resource/tasks/some-task.yml

Into this:

:
me: my-job
an:
get: some-resource
task: some-task
config:
  platform: linux
  image_resource:
    type: docker-image
    source:
      repository: some-repository
  run:
    path: sh
    args:
    - -c
    - |
      #!/bin/bash

      echo 42
    dir: ""
  inputs:
  - name: some-resource
    path: ""

Usage

nstall github.com/krishicks/concourse-pipeline-steamroller/cmd/steamroll

> config.yml <<EOF
source_map:
"some-resource": /path/to/resource/on/disk


mroll -p some-pipeline.yml -c config.yml

See the example in example/. Run scripts/create-example-config.sh to make a config.

About

A common pattern when writing Concourse pipelines is to have tasks in the pipeline refer to a task that comes from a resource (often, a git repository somewhere). If you want to modify that task for some reason you can either modify the task in the resource, commit and push the change, and then run your pipeline again, or you can just inline the entire task directly into the pipeline and just fly set-pipeline.

This does the inlining for you; it just needs you to have those tasks on disk somewhere, and provide a config that maps resource names to absolute paths on disk, such as:

urce_map:
ome-resource": /path/to/resource/on/disk
nother-resource": /some/other/place/on/disk

It's pretty basic for now. It doesn't presently handle renamed resources, e.g.:

t: renamed-resource
source: actual-resource
sk: some-task
le: renamed-resource/some-task.yml

If you use the above you'd need to use “renamed-resource” in your config to tell it where “actual-resource” is because it just yanks the root (“renamed-resource”) off of the file: directive to find the mapping in the config.

It also doesn't remove the (now superfluous) get: step; but you'd probably want to do that as it's no longer necessary and may lead to confusion. You could use yaml-patch to do that for you:

: remove
th: /jobs/get=renamed-resource