|
1 | 1 | <p align="center">
|
| 2 | + <a title="Codacy" href="https://app.codacy.com/manual/eine/issue-runner/dashboard"><img alt="Codacy grade" src="https://img.shields.io/codacy/grade/66830b37677941949d500400e2c7d1c8?longCache=true&label=quality&logo=codacy&style=flat-square"></a><!-- |
| 3 | + --> |
2 | 4 | <a title="Go Report Card" href="https://goreportcard.com/report/github.com/eine/issue-runner"><img src="https://goreportcard.com/badge/github.com/eine/issue-runner?longCache=true&style=flat-square"></a><!--
|
3 | 5 | -->
|
4 | 6 | <a title="godoc.org" href="https://godoc.org/github.com/eine/issue-runner/tool"><img src="http://img.shields.io/badge/godoc-reference-5272B4.svg?longCache=true&style=flat-square"></a><!--
|
|
9 | 11 | -->
|
10 | 12 | </p>
|
11 | 13 |
|
12 |
| -**issue-runner** is a toolkit to retrive, set up and run Minimal Working Examples (MWEs). MWEs are defined in a markdown file (such as the first comment in a GitHub issue), and external tarball(s)/zipfile(s)/file(s) can be included. The main use case for this toolkit is to be added to a GitHub Actions (GHA) workflow in order to monitor the issues in a repository and optionally report status/results by: |
13 |
| - |
14 |
| -- labelling issues as `reproducible` or `fixed?`, |
15 |
| -- adding a comment to the issue with logs and/or refs to jobs/artifacts, |
16 |
| -- and/or making test artifacts available through a CI job |
17 |
| - |
18 |
| -Nonetheless, the CLI tool can also be used to set up and test any MWE or issue locally. |
19 |
| - |
20 |
| -## Installation |
21 |
| - |
22 |
| -### Set up a GitHub Actions workflow |
23 |
| - |
24 |
| -The following block shows a minimal YAML workflow file: |
25 |
| - |
26 |
| -```yml |
27 |
| -name: 'issue?' |
28 |
| -on: |
29 |
| - issues: |
30 |
| - types: [ opened, edited ] |
31 |
| -jobs: |
32 |
| - mwe: |
33 |
| - runs-on: ubuntu-latest |
34 |
| - steps: |
35 |
| - - uses: eine/issue-runner@gha-v1 |
36 |
| - with: |
37 |
| - token: ${{ secrets.GITHUB_TOKEN }} |
38 |
| - allow-host: false |
39 |
| -``` |
40 |
| -
|
41 |
| -Note that `with` parameters are both optional: |
42 |
| - |
43 |
| -- `token` is required to report feedback (labelling issues or adding comments automatically). |
44 |
| -- `allow-host` enables/disables running scripts on the host (without a container). For security reasons, this is discouraged and this parameter defaults to `false`. |
45 |
| - |
46 |
| -### CLI tool |
47 |
| - |
48 |
| -The CLI tool is a static binary written in golang, which can optionally use `docker`. It can be downloaded from [github.com/eine/issue-runner/releases](https://github.com/eine/issue-runner/releases), or it can be built from sources: |
49 |
| - |
50 |
| -```sh |
51 |
| -git clone https://github.com/eine/issue-runner |
52 |
| -cd tool |
53 |
| -go build -o issue-runner |
54 |
| -``` |
55 |
| - |
56 |
| -<!-- |
57 |
| -```sh |
58 |
| -curl -L https://raw.githubusercontent.com/eine/issue-runner/master/tool/get.sh | sh - |
59 |
| -``` |
60 |
| - |
61 |
| -> You can give it a try at [play-with-docker.com](https://labs.play-with-docker.com/). Just create a node and run the command above. |
62 |
| ---> |
63 |
| - |
64 |
| -## Usage |
65 |
| - |
66 |
| -### Supported markdown syntax |
67 |
| - |
68 |
| -**issue-runner** scans the (markdown) body to extract: |
69 |
| - |
70 |
| -- Code blocks with either the body or the language definition string matching `:file:.*`: |
71 |
| - |
72 |
| -~~~md |
73 |
| -```sh :file: hello.sh |
74 |
| -#!/usr/bin/env sh |
75 |
| -echo "Hello world!" |
76 |
| -``` |
77 |
| -~~~ |
78 |
| -
|
79 |
| -~~~md |
80 |
| -```sh |
81 |
| -#!/usr/bin/env sh |
82 |
| -echo "Hello world!" |
83 |
| -#:file: hello.sh |
84 |
| -``` |
85 |
| -~~~ |
86 |
| - |
87 |
| -Note that, in the latter, `:file:` is prepended with a comment symbol that depends on the target language. |
88 |
| - |
89 |
| -- Attached/linked text files, tarballs or zipfiles with the name to the reference matching `:mwe:.*`: |
90 |
| - |
91 |
| -~~~md |
92 |
| -[:mwe:filename.ext.txt](URL) |
93 |
| -[:mwe:filename.tar.gz](URL) |
94 |
| -~~~ |
95 |
| - |
96 |
| -Since GitHub allows uploading files with a limited set of extensions, issue-runner expects the user to append `.txt` to attached source filenames. This extra extension is trimmed. The exception to rule above are tarballs, zipfiles or txt files. No extra extension needs to be appended. The content of these is automatically extracted. |
97 |
| - |
98 |
| -### Entrypoint |
99 |
| - |
100 |
| -One, and only one, of the code blocks should contain `:image:.*` instead of `:file:.*`. That file will be the entrypoint to an OCI container. For example: |
101 |
| - |
102 |
| -~~~md |
103 |
| -```sh :image: debian:buster-slim |
104 |
| -echo "Hello world!" |
105 |
| -``` |
106 |
| -~~~ |
107 |
| - |
108 |
| -~~~md |
109 |
| -```py |
110 |
| -#!/usr/bin/env python3 |
111 |
| - |
112 |
| -print('Hello world!') |
113 |
| - |
114 |
| -#:image: python:slim-buster |
115 |
| -``` |
116 |
| -~~~ |
117 |
| - |
118 |
| -> NOTE: to execute the MWE in multiple images, provide a space separated list. For example: `:image: alpine ghdl/ghdl:buster-mcode ubuntu:19.04`. |
119 |
| -
|
120 |
| -Alternatively, if no `:image:` is defined, the file which is named `run` will be used as the entrypoint to execute the MWE on the host. |
121 |
| - |
122 |
| -### CLI |
123 |
| - |
124 |
| -> NOTE: automatically labelling/commenting features are not included in the CLI tool. These features are implemented in the GitHub Action only. |
125 |
| -
|
126 |
| -At least one of the following references needs to be provided: |
| 14 | +**issue-runner** is a toolkit to retrive, set up and run Minimal Working Examples (MWEs). MWEs are defined in markdown files (such as the first comment in a GitHub issue), and external tarball(s)/zipfile(s)/file(s) can be included. It extracts sources to separate files, (optionally) invokes docker, executes the entrypoint, and cleans up. |
127 | 15 |
|
128 |
| -- Path or URL to markdown file: `issue-runner path/to/markdown/file.md` |
129 |
| -- Full URL to a GitHub issue: `issue-runner 'https://github.com/user/repo/issues/number'` |
130 |
| -- Short reference of a GitHub issue (see [GitHub Help: Autolinked references and URLs](https://help.github.com/articles/autolinked-references-and-urls/#issues-and-pull-requests)): `issue-runner 'user/repo#number'` |
| 16 | +The main use case for this toolkit is to be added to a GitHub Actions (GHA) workflow in order to monitor the issues in a repository and optionally report status/results by: |
131 | 17 |
|
132 |
| ---- |
| 18 | +- labelling issues as `reproducible` or `fixed?`, |
| 19 | +- adding a comment to the issue with logs and/or refs to jobs/artifacts, |
| 20 | +- and/or making test artifacts available through a CI job |
133 | 21 |
|
134 |
| -Providing a list of identifiers is also supported. For example: |
135 |
| - |
136 |
| -```sh |
137 |
| -issue-runner \ |
138 |
| - 'https://raw.githubusercontent.com/eine/issue-runner/master/tests/md/vunit-py.md' \ |
139 |
| - tests/md/vunit-sh.md \ |
140 |
| - 'VUnit/vunit#337' \ |
141 |
| - 'ghdl/ghdl#579' \ |
142 |
| - 'ghdl/ghdl#584' |
143 |
| -``` |
144 |
| - |
145 |
| -> NOTE: multiple references can be managed as a single MWE with flag `-m|--merge`. |
146 |
| -
|
147 |
| ---- |
148 |
| - |
149 |
| -MWEs defined in a single body can be read through *stdin*. For example: |
150 |
| - |
151 |
| -```sh |
152 |
| -cat ./tests/md/hello001.md | ./issue-runner - |
153 |
| -# or |
154 |
| -./issue-runner -y - < ./tests/md/hello003.md |
155 |
| -``` |
156 |
| - |
157 |
| -#### Docker container |
158 |
| - |
159 |
| -```sh |
160 |
| -docker run --rm -it \ |
161 |
| - -v //var/run/docker.sock://var/run/docker.sock \ |
162 |
| - -v issues://volume \ |
163 |
| - eine/issue-runner bash |
164 |
| -``` |
165 |
| - |
166 |
| -## Development |
167 |
| - |
168 |
| -**issue-runner** is composed of: |
169 |
| - |
170 |
| -- A JavaScript action with TypeScript compile time support, unit testing with Jest and using the GHA Toolkit. |
171 |
| -- A CLI tool written in golang. |
172 |
| -- A GHA workflow. |
173 |
| - |
174 |
| -### Build and test inside a container |
175 |
| - |
176 |
| -```sh |
177 |
| -docker run --rm -it \ |
178 |
| - -v /$(pwd)://src \ |
179 |
| - -w //src \ |
180 |
| - -v //var/run/docker.sock://var/run/docker.sock \ |
181 |
| - -v issues://volume \ |
182 |
| - golang bash |
183 |
| -``` |
184 |
| - |
185 |
| -### Internal execution steps |
186 |
| - |
187 |
| -Each time an issue is created or edited: |
188 |
| - |
189 |
| -<!-- |
190 |
| -issue metadata |
191 |
| -spawn container mounting files in /src |
192 |
| -report the results back to GitHub |
193 |
| ---> |
194 |
| - |
195 |
| -- ... |
196 |
| -- A temporal subdir is created. |
197 |
| -- Source files defined or referred in the first message of the issue are saved to separate files. |
198 |
| -- If a file with key `:image:` exists, it is saved as `run`. |
199 |
| -- `run` is executed either on the host or inside a container. |
200 |
| -- ... |
201 |
| - |
202 |
| -### Create a new release branch |
203 |
| - |
204 |
| -`master` branch of this repository contains the TypeScript sources of the action. However, these need to be compiled. A job in workflow `push.yml` is used to update branch `gha-tip` after each push that passes the tests. This kind of *auto-updated* branches need to be manually created the first time: |
205 |
| - |
206 |
| -```bash |
207 |
| -cp action.yml dist/ |
208 |
| -git checkout --orphan <BRANCH> |
209 |
| -git rm --cached -r . |
210 |
| -git add dist |
211 |
| -git clean -fdx |
212 |
| -git mv dist/* ./ |
213 |
| - |
214 |
| -git commit -am <release message> |
215 |
| -git push origin <release branch name> |
216 |
| -``` |
217 |
| - |
218 |
| -### Continuous integration |
219 |
| - |
220 |
| -After each commit is pushed to `master`: |
221 |
| - |
222 |
| -- The action is built, tested and published to branch `gha-tip`. |
223 |
| -- `golangci-lint` and `goreleaser` are executed in subdir `tool`, and `test.sh` is executed. |
224 |
| -- Action [eine/tip@gha-tip](https://github.com/eine/issue-runner/tip) is used to update tag `tip` and tool artifacts are published as a pre-release named `tip`. |
225 |
| - |
226 |
| -> NOTE: version `eine/issue-runner@gha-tip` of this action will automatically retrieve the CLI tool from [github.com/eine/issue-runner/releases/tag/tip](https://github.com/eine/issue-runner/releases/tag/tip). |
227 |
| -
|
228 |
| -## ToDo |
229 |
| - |
230 |
| -- [ ] Complete section 'Internal execution steps' of the README. |
231 |
| - |
232 |
| -- [ ] Properly handle exit codes / results. |
233 |
| - |
234 |
| -- [ ] Rethink the format/name of temporal directories created for each MWE. |
235 |
| - |
236 |
| -- Action: |
237 |
| - - [ ] Support labelling issues as `reproducible` or `fixed?`. |
238 |
| - - [ ] Support editing an existing comment published by github-actions bot, instead of adding a new one each time. |
239 |
| - - [ ] Support writing the logs and/or refs to jobs/artifacts in the body of the comment. |
240 |
| - - [ ] Support a `with` option/parameter to optionally make test artifacts available through a CI job. |
241 |
| - |
242 |
| -- CLI: |
243 |
| - - [ ] Add *golden* files. |
244 |
| - - [ ] Write `get.sh` script and uncomment related info in section 'Installation > CLI tool' of the README. |
245 |
| - |
246 |
| -- CI: |
247 |
| - - [ ] Implement publishing regular tagged (i.e. non-tip) releases. |
248 |
| - |
249 |
| -- [podman.io](https://podman.io/) |
250 |
| - - [ ] Check if podman is supported for local execution. |
251 |
| - - [ ] Check if podman is supported in GHA environments (even though docker is installed by default). |
252 |
| - |
253 |
| -- Security: |
254 |
| - - [ ] Ensure that github_token is not accessible for MWEs. |
255 |
| - - [ ] Which are the risks of executing MWEs on the host? |
256 |
| - |
257 |
| -- [arcanis/sherlock](https://github.com/arcanis/sherlock) |
258 |
| - - Close obsolete issues after each release |
259 |
| - |
260 |
| -<!-- |
261 |
| -TODO: publish issue-runner as a scratch-based docker image |
262 |
| -Check requisites, e.g. "indocker": |
263 |
| - - Check if the socket is available |
264 |
| - - Check if there is some mechanism to share data between sibling containers |
265 |
| ---> |
| 22 | +Nonetheless, the CLI tool can also be used to set up and test any MWE or issue locally. |
0 commit comments