fix: Use host environment for git to get root path #141
Conversation
|
Thanks for your bug report. Could you please describe in more details how to reproduce it? Regarding patch contributions, please have a look at https://github.com/siemens/kas/blob/master/CONTRIBUTING.md. What is specifically missing formally is a commit message (merge request threads can get lost, the git history stays) and the signed-off. Regarding how to address the issue: kas is intentionally not simply passing everything through from the host environment to ensure reproducibility in different setups. Once the issue can be reproduced, we will have to discuss how to address it best without violating that rule. BTW, reproduction will also allow writing a test case for this. |
|
Hi Jan, Thank you for your quick response and for sharing the contribution checklist. I created a demo project to illustrate this issue: The project contains a main configuration YAML file (machine/product/demo-board.yml), which includes a secondary configuration (machine/common/debug.yml). The secondary file is referenced relative to the Git repository path, which is determined by the get_root_path function. However, this function fails in GitLab CI due to different repository ownership, causing KAS to be unable to locate the secondary configuration file. Please find logs and link to CI below https://gitlab.com/zaporozhets/kas-demo/-/jobs/9126156151 Best, |
|
Thanks for the example. I already suspected that this happens in a GitLab CI environment. In the kas docker container we have a workaround for that in the entrypoint. The root cause is the same for your container and the kas container: Switching the user. Would it be possible for you to just apply the same workaround to your container entrypoint? |
|
Hi Felix, I appreciate you pointing me to the workaround. I added it to the Dockerfile instead of the entry point: # Work around gitlab-runner not aligning checked out repo ownership
# with our builder user
RUN git config --system safe.directory "*"It works(https://gitlab.com/zaporozhets/kas-demo/-/jobs/9127280910), so I'll stick with it for now. Wishing you a great day! Best, |
The GitLab CI runner mounts the $CI_PROJECT_DIR git project root from the outside but does not align the ownership of that directory with the user of the docker container. By that, git does not allow to perform any operation on that repository. As this is a well-known case, we mark that directory as a safe dir if running in GitLab CI. Xref: siemens#141 Signed-off-by: Felix Moessbauer <[email protected]>
The GitLab CI runner mounts the $CI_PROJECT_DIR git project root from the outside but does not align the ownership of that directory with the user of the docker container. By that, git does not allow to perform any operation on that repository. As this is a well-known case, we mark that directory as a safe dir if running in GitLab CI. Xref: siemens#141 Signed-off-by: Felix Moessbauer <[email protected]>
The GitLab CI runner mounts the $CI_PROJECT_DIR git project root from the outside but does not align the ownership of that directory with the user of the docker container. By that, git does not allow to perform any operation on that repository. As this is a well-known case, we mark that directory as a safe dir if running in GitLab CI. Xref: siemens#141 Signed-off-by: Felix Moessbauer <[email protected]>
|
@zaporozhets : I just sent a patch series to the kas ML that fixes the safe-dir handling also for non kas-container users. It would be great if you could have a look and check if patches 1 and 2 solve your issue as well. With that, you should not need to set any git safe dirs manually. https://groups.google.com/g/kas-devel/c/xPPsXQ--xs4 The patches are also available under https://github.com/fmoessbauer/kas/tree/fm/git-safe-dir-v1 |
|
@fmoessbauer, thanks. I'll try them today/tomorrow and let you know. |
The GitLab CI runner mounts the $CI_PROJECT_DIR git project root from the outside but does not align the ownership of that directory with the user of the docker container. By that, git does not allow to perform any operation on that repository. As this is a well-known case, we mark that directory as a safe dir if running in GitLab CI. Xref: siemens#141 Signed-off-by: Felix Moessbauer <[email protected]>
The GitLab CI runner mounts the $CI_PROJECT_DIR git project root from the outside but does not align the ownership of that directory with the user of the docker container. By that, git does not allow to perform any operation on that repository. As this is a well-known case, we mark that directory as a safe dir if running in GitLab CI. Xref: siemens#141 Signed-off-by: Felix Moessbauer <[email protected]>
The GitLab CI runner mounts the $CI_PROJECT_DIR git project root from the outside but does not align the ownership of that directory with the user of the docker container. By that, git does not allow to perform any operation on that repository. As this is a well-known case, we mark that directory as a safe dir if running in GitLab CI. Xref: #141 Signed-off-by: Felix Moessbauer <[email protected]> Signed-off-by: Jan Kiszka <[email protected]>
The GitLab CI runner mounts the $CI_PROJECT_DIR git project root from the outside but does not align the ownership of that directory with the user of the docker container. By that, git does not allow to perform any operation on that repository. As this is a well-known case, we mark that directory as a safe dir if running in GitLab CI. Xref: #141 Signed-off-by: Felix Moessbauer <[email protected]> Signed-off-by: Jan Kiszka <[email protected]>
Hi All,
A few years ago, Git introduced a safe directory policy that prevents Git commands from running, particularly in CI environments. This behavior breaks the
get_root_pathfunctionality because the command:returns the following error:
This MR updates get_root_path to allow Git to use the host gitconfig, including the defined exception directory.
Best,
Taras