PROTOTYPE: Magic files to access search results/modified files
Created by: mrnugget
NOTE FOR REVIEWERS: This is a prototype and should be treated as such, which means: let's review idea/design/feasibility instead of concrete implementation details (but if you do have concrete feedback on the implementation, feel free to leave it as such).
This is another prototype, next to https://github.com/sourcegraph/src-cli/pull/334, to solve the same thing: allowing step.run
commands to access specific files.
What this prototype does is to create magic files inside the container. The files contain lists of files, one filename per line. By using standard shell scripting, the run
commands can then access these files.
Example campaign spec:
name: a-magic-file-appeared
description: Updated description Hello World to READMEs
on:
- repositoriesMatchingQuery: lang:go fmt.Sprintf("%d", :[v]) patterntype:structural -file:vendor repo:automation-testing
steps:
# The two magic files right now are:
#
# /src/search-results contains search results in current repository, one per line
# /src/previous-step/modified-files contains files modified by previous step, one per line
#
# How do you make use of them?
#
# Option 1) Use a loop:
- run: cat /src/search-results | while read result; do xargs comby -in-place 'fmt.Sprintf("%d", :[v])' 'strconv.Itoa(:[v])' "${result}"; done
container: comby/comby
# Option 2) Use cat, which Unix-snobs say is useless here:
- run: cat /src/search-results | xargs comby -in-place 'fmt.Sprintf("%d", :[v])' 'strconv.Itoa(:[v])'
container: comby/comby
# Option 3) The Unix-snobs-approved variant: use the file as STDIN
- run: </src/search-results xargs comby -in-place 'fmt.Sprintf("%d", :[v])' 'strconv.Itoa(:[v])'
container: comby/comby
# We just ran comby three times. Now let's use `goimports` to format the modified files:
- run: cat /src/previous-step/modified-files | xargs goimports -w
container: unibeautify/goimports
# [...]
Screenshot
Details
This branch here builds on top of https://github.com/sourcegraph/src-cli/pull/334. But instead of using templating, it simply makes the data available in temp files that are then mounted into the container.
Drawbacks
- shell scripting required. It's not super advanced, but it also might not be as straightforward as the templating approach.