eine

@ioquatix, note that the messages in lines 4 and 5 are warnings. I don't know if those are related to the error in line 6. See for example https://github.com/ghdl/ghdl/runs/298621638#step:5:14

The execution might continue after those warning, although not providing a tty. Anyway, I have not been able to achieve using both `shell` and `run`. See actions/starter-workflows#95.

No. TBH, I was quite surprised about how this issue was handled. Alternatives so far are to manually force each tool (if options are provided) or to use docker containers...

Hi @dakale! Thanks a lot for giving this a thought! > What are you trying to do with this? Is it just color codes? (Im sure there are other implications...

@claudeleveille, it seems that you are running all the steps inside docker containers (`python:3.7.4-slim-buster`). As a result, you are not using the pty/tty (not) available on the host. Although the...

@claudeleveille, I run some further tests: https://github.com/1138-4EB/actions/tree/color - `container`: **non-coloured** output: https://github.com/1138-4EB/actions/runs/324389230#step:4:35 - `container_t`: **non-coloured** output: https://github.com/1138-4EB/actions/runs/324389161#step:4:35. Hence, I was wrong above. Adding `options: -t` has no effect, because GHA...

@dalehamel, that sounds interesting. Can you please elaborate? Is it possible to use it as a `shell`? ```yml steps: - uses: actions/checkout@v1 - shell: script -e -c {0} run: |...

That is probably a temporary connection error on GitHub's side. Can you please try restarting the workflow? Just in case, remove any asset from https://github.com/JoyMoe/OpenData/releases/tag/nightly starting with `tmp.*`.

The main problem here is that GitHub's internal connections seem not to be very stable, so rather frequently uploading artifacts as assets does produce failures. Until recently, *tip* could not...

@lazka, absolutely! If that is the case, that'd be an awesome catch! Let me run some local tests and I'll update the dockerfile.