Skip to content
Inline task.yml and task.sh files when they exist on disk
Branch: master
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
cmd/steamroll Add support for passing pipeline via stdin Jun 19, 2018
example Add README with example Jun 29, 2017
scripts Add README with example Jun 29, 2017
LICENSE Create LICENSE Jun 29, 2017
Makefile
README.md
concourse_pipeline_steamroller_suite_test.go
steamroller.go
steamroller_test.go Fix lint errors Mar 2, 2018

README.md

concourse-pipeline-steamroller

Convert this:

jobs:
- name: my-job
  plan:
  - get: some-resource
  - task: some-task
    file: some-resource/tasks/some-task.yml

Into this:

jobs:
- name: my-job
  plan:
  - 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

go get github.com/krishicks/concourse-pipeline-steamroller/cmd/steamroll

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

steamroll -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:

resource_map:
  "some-resource": /path/to/resource/on/disk
  "another-resource": /some/other/place/on/disk

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

- get: renamed-resource
  resource: actual-resource
- task: some-task
  file: 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:

- op: remove
  path: /jobs/get=renamed-resource
You can’t perform that action at this time.