Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify build environment handling, from sylabs 213 #255

Merged
merged 2 commits into from
Mar 12, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 8 additions & 0 deletions build_env.rst
Original file line number Diff line number Diff line change
Expand Up @@ -261,6 +261,14 @@ meaning that no intermediate decrypted data is ever present on disk. See
Environment Variables
*********************

You can set environment variables on the host to influence the behaviour of a
build. Note that environment variables are not passed into the build itself, and
cannot be accessed in the ``%post`` section of a definition file. To pass values
into a build, use the :ref:`templating / build-args support <sec:templating>`.

Environment variables that control a build are generally associated with an
equivalent CLI option. The order of precendence is:

#. If a flag is represented by both a CLI option and an environment variable,
and both are set, the CLI option will take precedence. This is true for all
environment variables with the exception for ``{ENVPREFIX}_BIND`` and
Expand Down
25 changes: 18 additions & 7 deletions definition_files.rst
Original file line number Diff line number Diff line change
Expand Up @@ -366,26 +366,37 @@ This section is where you can download files from the internet with
tools like ``git`` and ``wget``, install new software and libraries,
write configuration files, create new directories, etc.

The commands in the ``%post`` section run in a clean environment. Environment
variables from the host are not passed into the build. To pass values into a
build you should use the :ref:`templating / build-args support <sec:templating>`.

Consider the ``%post`` section from the example definition file above:

.. code:: {command}

%post
apt-get update && apt-get install -y netcat

NOW=`date`
echo "export NOW=\"${NOW}\"" >> ${ENVPREFIX}_ENVIRONMENT

This ``%post`` scriptlet uses the Ubuntu package manager ``apt`` to
update the container and install the program ``netcat`` (that will be
used in the ``%startscript`` section below).

The script also sets an environment variable at build time. Note that
the value of this variable cannot be anticipated, and therefore cannot
be set earlier in the ``%environment`` section. For situations like
this, the ``${ENVPREFIX}_ENVIRONMENT`` variable is provided. Assigning a
value to this variable will cause it to be written to a file called
``/.singularity.d/env/91-environment.sh`` that will be sourced by the
container at runtime.
The scriptlet also sets an environment variable called ``NOW`` to the current
date and time. It then writes an ``export`` statement for ``NOW`` into the file
that is pointed to by ``${ENVPREFIX}_ENVIRONMENT``. This demonstrates how to set
container environment variables (available when the container is run), that are
not known when the definition file is written. Because the value of ``$NOW`` is
only known when the ``date`` command in the ``%post`` scriptlet is run, it
cannot be added to the ``%environment`` section.

Directing output into ``${ENVPREFIX}_ENVIRONMENT`` will cause it to be written
to a shell script file called ``/.singularity.d/env/91-environment.sh`` that
will be sourced by the container at runtime. The ``export NAME=VALUE`` syntax is
needed to make the environment variable available to all processes that are
started in the container.

.. note::

Expand Down
Loading