Task inputs/outputs copy/move actions about atc

[concourse-bot]

Hi there!

We use Pivotal Tracker to provide visibility into what our team is working on. A story for this issue has been automatically created.

The current status is as follows:

• #115322493 Task inputs/outputs copy/move actions

This comment, as well as the labels on the issue, will be automatically updated as the status in Tracker changes.

[vito]

Does your build tool not support configuring where the output artifacts go? Most tools support that, e.g. ./configure --prefix <dir>, go build -o <dir>, etc. etc. This is a common pattern and one that doesn't seem to add coupling.

What we may be able to get working is overlapping inputs/outputs with the caveat that the output directory will still be empty by the time the build starts (i.e. you can't just auto-export a subdirectory of an input's bits). I'd be wary of adding much more orchestration though.

[aequitas]

A lot of tools do indeed, but as the list of inputs/outputs for a task grows i notice i need to write a lot of glue and logic just to make our current build scripts work with concourse (and still with our old tools/workflows). Right now that goes into a wrapper script, that works, but I think the task definition would be a nicer place to put this glue and logic.

[aequitas]

I think some of my use cases will be covered by the new 'params' option on 'task' steps. As a lot of our tooling uses env. vars.

Your suggestion for overlapping in/outputs also seems to cover a lot of the cases I would use my suggestion for. The globbing example was added as a 'nice to have' but I don't have any practical use for it yet.

[vito]

Eh I don't think this is going anywhere any time soon. It seems like a nice-to-have but the cost seems high relative to the reward. It also kind of blurs the line between behavior in the the .yml and in the script, which may add some unwanted mental overhead when iterating on tasks.

I'll close this for now.