Octo cli exits 159 (...DOTNET_BUNDLE_EXTRACT_BASE_DIR...)

Integration
1

version: 7.4.4 (from https://apt.octopus.com)
host: debian stretch (docker container)

If DOTNET_BUNDLE_EXTRACT_BASE_DIR is not set, any cli use in a container with a non-existent --user|-u exits 159. But simply adding an env --env|-e resolves. Why doesn’t octo do this using sane defaults?

Suppose my org uses octopus deploy and I work in js and python, and use octo to typical pkg operations. Should I really have any care what dotnet is or the purpose of this env var?

steps to repro:

FROM buildpack-deps:stretch
RUN apt update apt install -y --no-install-recommends gnupg curl ca-certificates apt-transport-https \
    && curl -sSfL https://apt.octopus.com/public.key | apt-key add - \
    && sh -c "echo deb https://apt.octopus.com stable main > /etc/apt/sources.list.d/octopus.com.list" \
    && apt update && apt install -y octopuscli=7.4.4

$ docker build -t wat . 

$ docker run --rm -it wat octo --version
7.4.4

$ docker run --rm -it -u 87654 wat octo --version
Failure processing application bundle.
Failed to determine location for extracting embedded files
DOTNET_BUNDLE_EXTRACT_BASE_DIR is not set, and a read-write temp-directory couldn't be created.
A fatal error was encountered. Could not extract contents of the bundle

$ docker run --rm -it -u 87654 -e DOTNET_BUNDLE_EXTRACT_BASE_DIR=/tmp wat octo --version
7.4.4
4

Hi,

Sorry we missed this, we will investigate and keep you updated.

5

Hi,

Apologies for taking so long to get back to you, I finally understand what’s going on! Unfortunately this doesn’t appear to be behaviour defined by our CLI but instead by .NET and Docker.

It appears that this is default behaviour of a .NET Core 3.0 Single Page App by design. I’ve managed to locate reference to this in their design documentation here. It specifies the conditions for evaluating the location of the extraction directory.

I also found this article which discusses common issues with using docker as a non-root user, which could help explain the behaviour you are seeing. It seems that if the container doesn’t know about the user, then it is unable to set a $HOME directory, and so then .NET is unable to locate the directory to use.

Hopefully this clarifies why the ENV variable is required to be set when the container doesn’t know about the user. Feel free to let me know if you have any questions or would like any part explained further!

Best Regards,
Finn

6

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.