Potential improvements

[epedroni]

A few things I noticed while building these images for use in GitLab CI:

• python3-pypathlib is apparently not available in Ubuntu 22.04. I was able to build at least peta-vivado-2022.1 without installing this, so maybe it can be removed from the README
• I see that the Xilinx tool settings are sourced in .bashrc. This does not run for me when using the image in GitLab CI, which seems to be known behaviour. It's easy to source the settings in the CI pipeline script, but the CI pipeline would have less boilerplate code if this worked automatically in the image (as it does when running with docker compose).
• Similar to the point above: in GitLab CI the docker compose file is not used, so the workspace directory with the symlinks to workspace-template is not automatically mounted. I worked around this by using workspace.template directly, so are the symlinks needed at all?

[Rubusch]

Wow, thank you so much for this feedback! As I mentioned, I'm about to rework the multistaged docker into a single docker setup, but first I'll be on holiday for a while (and probably rather offline).

I'll put python3-pypathlib (README) on my list, as also the 'known behavior' issue and link you mentioned. Great!

About the usage of docker-compose, as I understand you, I'm somehow undecided here. AFAIK every docker-compose setup can also be equally used directly with calls to docker tools and passed arguments. At least in my setup it should be possible to start the container with plain docker commands.

To be honest, in comparison to plain old docker commands, the docker-compose approach for facilitates a lot by shortening the command + args list having a yaml file for the parameters. Wrapping then a script around IMHO still makes sense, since the script is pretty simple.

Nevertheless, when it comes to CI/CD + plugins, usually here i'm also installing docker-compose first, since this is the use case for a supposed user, e.g. me, and I want to have this tested. The more it gets into a "jost for automation", though, docker-compose probably makes not so much sense. Yet another layer of abstraction, i.e. increased complexity, more maintenance when adjusting something, hassle with the tooling. So, I see your point, many CI/CD machines have plugins that need to be parametrized then they take over completely just operating on a Dockerfile. I'll have a look into that. Good point.