Initial docker image build file which support dev.

[Readon]

Context, Motivation & Description

Impact on code generation

Checklist

- [ ] Unit tests were added
- [ ] API changes are or will be documented:

• using Scaladoc comments: /** */?
• on RTD?
• thanks to a new tracking issue on RTD?

[Readon]

The docker image is hosted by GitHub Packages now.

[Readon]

The size of images has been reduced by 1 GB now.
it can be the base image of various usage.

All compiled executables are put in /opt directory.

Personally, I recommend use podman to avoid the file permission problems.

[andreasWallner]

I just tried the container on:

• github codespaces (just add this file https://github.com/andreasWallner/spinalStuff/blob/master/.devcontainer/devcontainer.json to your repo and you should be able to open the codespace via the Code button on github)
• locally w podman (I guess you knew it works there... ;-) )
• build the documentation examples with it (I'd change that build step there to use the latest container
• our company CI (OpenShift)

What I could not try is in an airgapped environment as you are currently not copying the caches to the container.

It did not work on our company CI due to access rights (it forces a random user). I had a look at the Dockerfile that I build a while ago for that, and there I set the environment such that regardless of user the same sbt/cache directories are used via adding this before installing anything sbt related:

ENV SBT_OPTS="-Dsbt.override.build.repos=true -Dsbt.boot.directory=/sbt/.sbt/boot -Dsbt.global.base=/sbt/.sbt -Dsbt.ivy.home=/sbt/.ivy2 -Duser.home=/sbt -Dsbt.global.localcache=/sbt/.sbt/cache"

This way all users will use the same directory for cache, etc. and since the GID is 0 it works out.

One other question: is there a reason why you install Java11 instead of the current LTS (17) (11 is the LTS from 2018)

[Readon]

Good work!

What I could not try is in an airgapped environment as you are currently not copying the caches to the container.

I am also struggling with the problems that might meet in airgapped environment.
I have tried this in FormalTutorial's docker and server branches.
The docker branch included the jars for vscode dev containers, however it still requires to install metal related jars while startup.
The server branch is still under test which include a code-server in it.

It did not work on our company CI due to access rights (it forces a random user). I had a look at the Dockerfile that I build a while ago for that, and there I set the environment such that regardless of user the same sbt/cache directories are used via adding this before installing anything sbt related:

ENV SBT_OPTS="-Dsbt.override.build.repos=true -Dsbt.boot.directory=/sbt/.sbt/boot -Dsbt.global.base=/sbt/.sbt -Dsbt.ivy.home=/sbt/.ivy2 -Duser.home=/sbt -Dsbt.global.localcache=/sbt/.sbt/cache"

This way all users will use the same directory for cache, etc. and since the GID is 0 it works out.

This is a good idea to avoid installing related packages for each user.

One other question: is there a reason why you install Java11 instead of the current LTS (17) (11 is the LTS from 2018)

Emm, I am really not an expert of Java, so that I only tried Java8 and found that its package on Ubuntu depends on X11 related packages which make the disk occupation large. Then Java11 is adopted.
I found that even Java8 is still widely adopted in the community. Do you think Java17 is a significant feature that required? I can try to switch to it.

[andreasWallner]

To get my images to work w/o internet connectivity I had to actually run sbt update in them (also for the test) so that everything is there. Can't speak to metals, did not use that there (it's a while back and metals was quite unstable for me back then)

There is no significant feature other than speed improvements made over ~3 years when you go to openjdk-17-jdk-headless

[Readon]

I am currently rethinking the design purpose of docker images.

There is no need to release an image for each version if we just want to build a compile and test environment for spinalhdl itself. A fixed version of the image should be sufficient. I have created a PR in SpinalHDL/docker#6 which can create a docker image with sufficient tools.

If we want to provide a base image for custom projects, then it makes sense to release for each version.
So that publish the SpinalHDL lib locally in the docker with version tag to be released would be a solution.
Then user can download the image with corresponding version and use it directly with almost all dependencies.
This has testing in Readon/SpinalHDL master branch.
However, this solution might install compile-related packages which may not be required at runtime.

[Readon]

I close this temporarily, the dev branch is frequently changed during test, it would not be a good practice to run test on it every time.

[andreasWallner]

FYI this is what I do at work (because our CI machines to not have internet access) - I run my project once to fill the caches and then continue to use that image as long as possible ;-)