Skip to content
This repository has been archived by the owner on Nov 2, 2022. It is now read-only.

Add global tool wrapper #163

Closed
viceice opened this issue Mar 18, 2021 · 6 comments
Closed

Add global tool wrapper #163

viceice opened this issue Mar 18, 2021 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@viceice
Copy link
Member

viceice commented Mar 18, 2021

What to do
To have better compability with other workflows we should add global wrapper for installed tools.
Those wrapper should source BASH_ENV and then call normal tool, so we have our prepared env loaded.

Sample Jenkins

  • Container is started like docker run ... -d --rm renovatebot/node cat
  • creating a /path/to/run.sh shell script with commands at shared dir.
  • Executing commands by docker exec <container-id> sh /path/to/run.sh

The exec is calling default sh command in env, which will be linked to dash on our ubuntu image.
Overwriting it to bash won't help, as it won't source BASH_ENV.
exec is also not calling entrypoint, so again no BASH_ENV sourcing.

Solution

creating shell wrapper like we did for node < 15

if [[ ${MAJOR} < 15 ]]; then
# backward compatibillity
shell_wrapper node
fi

# use this if custom env is required, creates a shell wrapper to /usr/local/bin
function shell_wrapper () {
local FILE="/usr/local/bin/${1}"
check_command $1
cat > $FILE <<- EOM
#!/bin/bash
if [[ -f "\$BASH_ENV" && -z "${BUILDPACK+x}" ]]; then
. \$BASH_ENV
fi
if [[ "\$(command -v ${1})" == "$FILE" ]]; then
echo Could not forward ${1}, probably wrong PATH variable. >&2
echo PATH=\$PATH
exit 1
fi
${1} \${@}
EOM
chmod +x $FILE
}

@viceice viceice added the enhancement New feature or request label Mar 18, 2021
@viceice viceice self-assigned this Mar 18, 2021
@viceice
Copy link
Member Author

viceice commented Mar 18, 2021

This would also allow doing docker exec <container> go --version and other commands, which currently fail because of not loading our env

@rarkins
Copy link
Contributor

rarkins commented Mar 18, 2021

So for each tool x, it would actually call a wrapper of ours, which would do env export and then call the real x?

Would the wrapper locate the real x using $PATH somehow (e.g. finding the second x in the path after itself) or would it simply "know" which path for x to use because we installed it?

@viceice
Copy link
Member Author

viceice commented Mar 18, 2021

the wrapper sources our env, after it the wrapper will be later in path so it simply calls the real x then. thats how it currently works for node.

@viceice viceice mentioned this issue Mar 22, 2021
3 tasks
@viceice
Copy link
Member Author

viceice commented Mar 23, 2021

Missing parts:

  • add shell wrapper for install-pip
  • add shell wrapper for install-gem
  • java
  • erlang
  • docker
  • php
  • composer

@viceice

This comment has been minimized.

@viceice viceice closed this as completed Apr 7, 2021
@viceice
Copy link
Member Author

viceice commented Apr 8, 2021

Duplicate of containerbase/base#21

@viceice viceice marked this as a duplicate of containerbase/base#21 Apr 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants