-
Notifications
You must be signed in to change notification settings - Fork 386
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
Common-utils: various cleaning things from other pr. #653
Common-utils: various cleaning things from other pr. #653
Conversation
Tests are failing locally due to a permissions issue writing to Present in debian:bullseye and alpine
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for contributing the PR, left some comments!
Testing the marked flag I have is a little hard since I would need to build a base image within a test, since the avaliable base images have old version of the source code, and thus no flag. |
Looks like the recent commits are causing multiple test failures. See https://github.com/devcontainers/features/actions/runs/5868233855?pr=653 |
Do you understand this -- error with the coreutils cp? @samruddhikhandale . Couldn't re create locally
from this code
see extended log See local test (issue not reproduced):
test with absolute paths
Tests stoped failing when changed to coping the template path to both destinations... Should the link exist? I'm not sure, its just getting copied to root. If scripts append to the user, is it appropriate for root rc to reference it in the context of a dev container? |
@@ -13,6 +13,8 @@ check "zsh" zsh --version | |||
check "ps" ps --version | |||
check "Oh My Zsh! theme" test -e $HOME/.oh-my-zsh/custom/themes/devcontainers.zsh-theme | |||
check "zsh theme symlink" test -e $HOME/.oh-my-zsh/custom/themes/codespaces.zsh-theme | |||
check "zsh theme filename" test -e $HOME/.oh-my-zsh/custom/themes/codespaces.zsh-theme |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would take the meaning of -e and symlink to mean xor... not sure @samruddhikhandale
src/common-utils/main.sh
Outdated
# Given previous step configured ~/.zshrc, | ||
# When installOhMyZshConfig is false, done before INSTALL_ZSH since | ||
# Or where installOhMyZshconfig false, and installZsh false | ||
# Then remove the file |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the PR changes installOhMyZshConfig
would behave completely different as compared to other Feature options.
For eg. Let's say an image (say X
) installs common-utils as follows -
"features": {
"common-utils": {
"installZsh": true,
}
}
Then a user creates their devcontainer.json
as 👇
{
"image": "X",
"features": {
"common-utils": {
"installZsh": false
}
}
}
"installZsh": false
Does this mean the Feature should remove the zsh
installation? I don't think that the Features should remove an existing functionality, however, should only update or add new tools/configs/themes.
When a user add a Feature to their devcontainer.json
, it is assumed that the "installZsh": false
option would NOT install zsh
but it doesn't mean that it should remove the already existing zsh
. This behavior could create confusions and removing something is always a bit risky. I think we should avoid this approach.
@naturedamends Let me know what you think!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe, remove the file, if zshrc exists and installZshConfig false and installZsh true?
Or do you not like the file being removed at all?
Should I remove the source of zshrc added in tests? Such that it's not executed within within build runtime. Then again.. it's a container
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or do you not like the file being removed at all?
This ☝️
You never know if the zsh config has been modified by the dockerfiles (or something else), hence, it's best to avoid removing anything. Also, removing config makes sense only if the Feature had an option like removeZshConfig
, but doesn't seem like that's needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hose about linking ~/.zshrc to .zshrc.devcontainer.
Then downstream can handle, or ln -sf?
# ********************************* | ||
# ** Ensure config directory ** | ||
# ********************************* | ||
user_config_dir="${user_home}/.config" | ||
if [ ! -d "${user_config_dir}" ]; then | ||
mkdir -p "${user_config_dir}" | ||
chown ${USERNAME}:${group_name} "${user_config_dir}" | ||
fi | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
features/src/common-utils/main.sh
Lines 392 to 400 in 1724e14
if [ "${USERNAME}" = "root" ]; then | |
user_home="/root" | |
else | |
user_home="/home/${USERNAME}" | |
if [ ! -d "${user_home}" ]; then | |
mkdir -p "${user_home}" | |
chown ${USERNAME}:${group_name} "${user_home}" | |
fi | |
fi |
user_home
, hence, should this be added after that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good catch. I want a clean home directory, so if im going to program this, I want it before any rc files. Not sure how much of a pain this is going to be
I came to the conclusion that you would not want any related flags in common-utils
Is the shell-setup feature going to be in features repo?
Then would it be prudent to add a flag to prevent any rc generation here
Thus you can enable the following to get equal functionality:
Common-utils rc false
Shell-setup shell zsh
I'm not familiar with any other fancy shells. Other than one I heard of that has a consistent output table format.
Would you consider adding a shell-setup to the features repo?
Sorry for bad grammar on tablet
# Copy files to alternate user if one is specified | ||
cp -rf "${user_omz_filepaths[@]}" /root | ||
# Set permissions for root user | ||
chown -R root:root "${omz_added_filesnames[@]/#//root/}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Curious, why is this needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Security. User scripts making it into root and being sourced.
Would be tempted to copy from a mktmp-d. To prevent copying any unknown files
Ie custom shell scripts
Or scripts appended to users linked template
Nvm. I will close pr.
Proposal
Enable usage of the
installOhMyZshConfig
flag within Microsoft base dev container images.Since images may have had previous installs which come with commom-utils. This allows the config option to function as stated.
failed proposal
This is now just cleaning up the file and fixes some issues with the flag for non root usernames.