SingularityCE 4.1.0 Release Candidate 1

[dtrudg]

SingularityCE 4.1.0-rc.1 is the first release candidate for the upcoming SingularityCE 4.1.0 release. This release candidate is intended to allow testing of new functionality and existing workflows. We welcome any and all feedback you are able to provide.

The release candidate is not intented for production use. Please see the latest 4.0.3 stable release instead.

Changed defaults / behaviours

• In native mode, SIF/SquashFS container images will now be mounted with squashfuse when kernel mounts are disabled in singularity.conf, or cannot be used (non-setuid / user namespace workflow). If the FUSE mount fails, Singularity will fall back to extracting the container to a temporary sandbox in order to run it.
• In native mode, bare extfs container images will now be mounted with fuse2fs when kernel mounts are disabled in singularity.conf, or cannot be used (non-setuid / user namespace workflow).

New Features & Functionality

• The registry login and registry logout commands now support a --authfile <path> flag, which causes the OCI credentials to be written to / removed from a custom file located at <path> instead of the default location ($HOME/.singularity/docker-config.json). The commands pull, push, run, exec, shell, and instance start can now also be passed a --authfile <path> option, to read OCI registry credentials from this custom file.
• A new --keep-layers flag, for the pull and run/shell/exec/instance startcommands, allows individual layers to be preserved when an OCI-SIF image is created from an OCI source. Multi layer OCI-SIF images can be run with SingularityCE 4.1 and later.
• Singularity will now build OCI-SIF images from Dockerfiles, if the --oci flag is used with the build command. Provide a Dockerfile as the final argument to build, instead of a Singularity definition (.def) file. Supports --build-arg / --build-arg-file options, --arch for cross-architecture builds, --authfile and other authentication options, and more. See the user guide for more information.
• Docker-style SCIF containers (https://sci-f.github.io/tutorial-preview-install) are now supported. If the entrypoint of an OCI container is the scif executable, then the run / exec / shell commands in --oci mode can be given the --app <appname> flag, and will automatically invoke the relevant SCIF command.
• A new --tmp-sandbox flag has been added to the run / shell / exec / instance start commands. This will force Singularity to extract a container to a temporary sandbox before running it, when it would otherwise perform a kernel or FUSE mount.

Deprecated Functionality

• The experimental --sif-fuse flag, and sif fuse directive in singularity.conf are deprecated. The flag and directive were used to enable experimental mounting of SIF/SquashFS container images with FUSE in prior versions of Singularity. From 4.1, FUSE mounts are used automatically when kernel mounts are disabled / not available.

Thanks / Reporting Bugs

Thanks to our contributors for code, feedback and, testing efforts!

As always, please report any bugs to: https://github.com/sylabs/singularity/issues/new

If you think that you've discovered a security vulnerability please report it to: security@sylabs.io

Have fun!

Downloads

Source Code

Please use the singularity-ce-4.1.0-rc.1.tar.gz download below to obtain and install SingularityCE 4.0.3. The GitHub auto-generated 'Source Code' downloads do not include required dependencies etc.

Packages

RPM / DEB packages are provided for:

• Ubuntu 20.04 (focal)
• Ubuntu 22.04 (jammy)
• RHEL/CentOS 7 (el7)
• RHEL/CentOS/AlmaLinux/Rocky 8 (el8)
• RHEL/CentOS/AlmaLinux/Rocky 9 (el9)

These packages were built with Go 1.21.6

---

This discussion was created from the release SingularityCE 4.1.0 Release Candidate 1.

[radusuciu]

Nice release!

Question about the singularity build --oci feature. Is there current or planned support for multi-stage docker files? Something like: singularity build --target stage2 --oci cowsay.sif Dockerfile

[dtrudg]

This isn't explicitly planned yet, but it could potentially be added. We want the flags for the Dockerfile builds to match the non-OCI Singularity builds as closely as possible to minimise confusion. Therefore, various things that docker build offers haven't been wired up here despite buildkitd supporting them. We'd want to explore how --target could be implemented for native Singularity definition file builds first.

If this is a feature that would be significant for you, please open a 'feature request' issue (https://github.com/sylabs/singularity/issues/new/choose), ideally explaining how this would specifically aid your workflows. Thanks!

[radusuciu]

Thanks for the reply and clarification. I'm not yet sure how significant this feature is for me - I don't have much experience with singularity but arrived at this while transitioning from separate Dockerfiles to a multi-stage one. Currently the project uses spython to go from a Dockerfile to a Singularity .def but I wasn't sure what the best approach was and whether the features that are about to land could simplify things.

[dtrudg]

Updated documentation for the upcoming 4.1.0 release can now be found at:

https://docs.sylabs.io/guides/4.1/admin-guide/

https://docs.sylabs.io/guides/4.1/user-guide/

It is not yet linked from sylabs.io/docs - this will happen upon the stable release of 4.1.0. Please use the links above directly as you look at the release candidate.