HOME variable is not set

We are trying to build an custom enviroment.
When we run on reana the HOME is set to /
The CASA software is failing to run.
Are there way to tell that HOME to set to REANA_WORKSPACE?
Here is the example of docker:

# Use a base Linux distribution
FROM ubuntu:latest
# Set environment variables
ENV CASA_DIR /usr/local/casa
# Install system-level dependencies (adjust as needed)
RUN apt-get update && apt-get install -y \
    wget \
    build-essential \
    libssl-dev \
    zlib1g-dev \
    # Add other necessary packages here \
    && apt-get clean
# Download CASA package (replace with the actual download link)
RUN wget -q https://casa.nrao.edu/download/distro/casa-pipeline/release/linux/casa-6.5.4-9-pipeline-2023.1.0.124-py3.8.tar.xz -O /tmp/casa.tar.gz
# Extract CASA package
RUN mkdir -p $CASA_DIR && tar -xvf /tmp/casa.tar.gz -C $CASA_DIR --strip-components=1
# Set PATH environment variable to include CASA binaries (adjust as needed)


version: 0.3.0
    - J0614+6108-spw32.ms
    - listobs.py
    - .env
  type: serial
      - environment: 'gitlab-p4n.aip.de:5005/p4nreana/reana-env:casa.10534'
           - pwd
           - env
           - casa ~/

CASA exits with a non-zero status : unexpected exception raised in casashell init: PermissionError [Errno 13] Permission denied: ‘/.casa’

Thank you.

found a workaround by expirting HOME=./ in a docker
(totally forgot about this)

Hi @arm2arm

Good that you found a workaround. Just wanted to comment on a couple of related things:

  1. If you write pwd, env and casa as separate items in the commands list, then they will be executed as independent Kubernetes jobs after after another. So for debugging purposes of this kind, you may want to use the command chain pwd && env && casa in one single line.

  2. Note that if a command need some environment variables, it should not be fully necessary to modify the Docker image; it may be sufficient to pass it on the command line in front of the command, probably as follows:

      - HOME=$$PWD casa ...
  3. You can also take advantage of the environment variable REANA_WORKSPACE that is pointing to the workspace of the given workflow, for example

      - echo $$REANA_WORKSPACE

(BTW note the double dollar sign so that the item won’t be expanded by reana.yaml parameter substitution process, but rather be treated as an environment variable.)

Perhaps some of these tips may come handy in certain situations to allow you to always refer to the dynamic workflow’s workspace path in an unified way.