ci: use HDL container to prepare for bitstream building #230
Conversation
| @@ -5,6 +5,19 @@ on: [push, pull_request] | |||
| jobs: | |||
| build: | |||
| runs-on: ubuntu-18.04 | |||
| container: | |||
| image: ghcr.io/hdl/debian-buster/impl:prjtrellis | |||
There was a problem hiding this comment.
I suggest building the image once only in one job, and then have a second (matrix) job for running the tests/builds. Moreover, I would recommend building the image in a different workflow.
In any case, you can use the default token for pushing your custom image to ghcr.io/litex-hub....
It's ok to use ghcr.io/hdl/debian-buster/impl:prjtrellis (or some other image from hdl/containers) as a base. My suggestions are about not building a custom image multiple times in each CI run.
| pip3 install setuptools | ||
| pip3 install requests | ||
| pip3 install pexpect | ||
| apt-get -qy update |
There was a problem hiding this comment.
This is one of the steps that should not be repeated, because doing so does not add any value.
With regard to the specific list of packages, python3 is installed already in all ghcr.io/hdl/debian-buster images. See https://github.com/hdl/containers/blob/main/debian-buster/base.dockerfile#L26.
| pip3 install pexpect | ||
| apt-get -qy update | ||
| apt-get -qy install wget build-essential python3 python3-pip verilator libevent-dev libjson-c-dev \ | ||
| device-tree-compiler python3-requests python3-pexpect | ||
|
|
||
| # Install (n)Migen / LiteX / Cores | ||
| - name: Install LiteX |
There was a problem hiding this comment.
This step should also be common and executed once only.
|
|
||
| # Install (n)Migen / LiteX / Cores | ||
| - name: Install LiteX | ||
| run: | | ||
| wget https://raw.githubusercontent.com/enjoy-digital/litex/master/litex_setup.py | ||
| python3 litex_setup.py init install --user | ||
| python3 litex_setup.py init install | ||
|
|
||
| # Install RISC-V GCC | ||
| - name: Install RISC-V GCC |
There was a problem hiding this comment.
This seems to be specific for the testing in this repo. Hence, it might be sensible to have two images. One for Litex, and another one for RISC-V GCC. Ideally, it would not be necessary to have both of them in the same image. See https://hdl.github.io/containers/#_usage.
See also hdl/containers#16. That is, the Litex image might be upstreamed to hdl/containers.
|
Thanks for the comments, @umarcor! Initially, I thought about creating a separate Docker container for these builds, but opted to stay with a simple matrix workflow for now:
So I'd suggest starting with a simple workflow like this in the linux-on-* repos. When this works with the current master versions, it should be relatively easy to translate that known-good version into a proper HDL container (at least for someone with Docker experience :). At that point we can simplify the workflows here. |
|
Thanks @jluebbe, having a way to automate bitstream generation is very interesting. The aim here is however a bit different than the CI in place in the different LiteX repositories which are there to catch regressions and provide quick feedback. If we work on automatic bitstreams generation for Linux-on-LiteX-Vexriscv, here are a few points we should take into account:
I was also thinking about having a local machine doing this weekly (and with some boards attached to it to also check for regression on bistreams). In terms of CI in this repository, we should probably first get back to what was done with Travis-CI:
So automatic bitstreams generation is a very interesting topic but should probably be done in a different repository first. We could explore/discuss this all together in a Linux-on-LiteX-Vexriscv issue with one of your repository used for the experiment or could also create a repository in litex-hub to explore this is you prefer. |
My initial goal was to have a replacement for the #164 issue which contains manually pre-built images. Already this simple workflow would save manual work, make it more reproducible and allow larger artifacts. As I was starting with Linux-on-LiteX-* and trying to reproduce a working bitstream, I kept running into regressions where the parts had diverged (as building master is the default) and was wondering if those were just local problems in my setup. Having a current CI check for comparison would have avoided some frustration. :)
OK, that's just a config option in the workflow file. As long as it's relatively current, I'm fine with that.
No, as far as I know, the necessary tools are not publicly available (have not checked though). The code is generated though (for the arty board, as before).
I'd see that as the next step after having reliably built bitstreams. From my perspective the Linux side is comparatively simple. ;)
That would certainly be useful, but I think that's out of scope for this PR. :) I'm adding the necessary support to our HW control framework in labgrid-project/labgrid#781, which would also one step of the way to integrate it with https://kernelci.org/.
OK. You mean as with https://github.com/litex-hub/linux-on-litex-vexriscv/blob/9d83552c609f66050ccca8c4624b29a2a62ad076/.travis.yml ?
This should be relatively easy to add to the workflow in this PR. Perhaps also only for some canary boards?
That should maybe added in a different PR (due to the different tools required, simulation time and tooling to detect a successful boot). One Linux image could be reused for multiple tests. For now, we could attach manually tested artifacts to tags/releases.
Hmm, as this PR only expands on the current workflow, I had expected to improve incrementally in this repository. Even this simple test already shows the current issue with pythondata-cpu-vexriscv_smp. |
|
In fact I'm trying to keep CI very simple and just run python unit-tests that can also be run locally, so this PR is indeed adding back some tests that were done with Travis-CI previously but through CI features while I would prefer going with python unit-tests. This CI script is also common for all LiteX repositories and I'd like to keep it very close to it for now to simplify development/maintenance of the project. So we won't be able to merge this CI workflow in Linux-on-LiteX-VexRiscv, but I still think this is addressing interesting points that we could discuss in an issue and could be developed externally (at least for now). |
|
With c13cd8e we are now using a python unit-test to check the build (software/gateware generation) of all boards + test cpu_count=1, 2, 4 on Arty. This a first step but should demonstrate the direction I'd like to go for CI tests in this directory. |
Hmm, by hard-coding the board name in the python test, we can't easily use the parallelism and dependencies provided by a workflow. With out synthesis, the impact is small for now, but trellis and nextpnr would benefit a lot. Also using upload-artifact seems straight forward with one job per board. |
|
@jluebbe: I'm sorry, I know you can see lots of benefits in your approach (and you are probably right), but as a the main maintainer of this repository, I just want to have something simple and convenient to work with, which is not the case (for me) with complex CI workflows. As explained above, I also think CI and bitstreams generation should be de-correlated, so we'll keep the CI simple with python unit-tests but I created #232 to discuss building the Linux images and #233 to discuss and experiment with automatic bistreams generation. |
This adds the groundwork for automatically building bitstreams via GitHub Actions. The artifacts are then available for download from the build page: https://github.com/jluebbe/linux-on-litex-vexriscv/actions/runs/847499253
Currently, the build fails for trellisboard, ecpix5 and de10nano, as the required cluster netlists are not in the https://github.com/litex-hub/pythondata-cpu-vexriscv_smp repository.