git commands cannot be performed in pipeline

[Timple]

I have a pipeline which (indirectly) calls git rev-parse --show-cdup.

This works in bitbucket, but using pipelines.phar I get:

fatal: not a git repository (or any of the parent directories): .git

Is there any effort being done here which removes the .git directory?

[ktomk]

No. If you use keep on failure and enter with a shell, does /app/.git exists? @Timple

[Timple]

Ah, there actually is.

Thanks for the tip on --keep. Running git rev-parse --show-cdup in the container gives:

root@b327e678ab84:/app# git rev-parse --show-cdup
fatal: detected dubious ownership in repository at '/app'
To add an exception for this directory, call:

	git config --global --add safe.directory /app

Seems like bitbucket does deem these repositories safe?

[ktomk]

Hmm, I know that error from git and this explains your original question as /app/.git is there it's just that git(1) does not consider it safe to without prior user interaction/configuration.

Interestingly I don't have it in my testing with pipelines, so a couple of questions to make a more educated guess on how this could become a zero-configuration when running a git pipeline (and also reproducing on my end):

Could you be so kind and provide the following details?

• Which user owns /app in your scenario and which user executes the container?
• Are you making use of the --user flag?
• Do you run Docker rootless or do you use a docker replacement?
• What is the output of git version --build-option both on your box and inside the container
• Docker version could be useful, too.

My understanding is, it should be generally safe to add the /app deployment directory to the global (or system configuration) in a build container.

[Timple]

I'm not behind a linux machine at the moment.

But to reproduce this should be enough:

definitions:
  caches:
    pre-commit: ~/.cache/pre-commit
  steps:
    - step: &nobleo-pre-commit
        name: Pre-commit
        image: salcatroppa/pre-commit
        caches: [pre-commit]
        script: [pre-commit run --all-files --verbose]

pipelines:
  default:
    - step: *nobleo-pre-commit

(perhaps you actually need the .pre-commit-config.yaml file):

repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v2.3.0
    hooks:
    -   id: check-yaml

[Timple]

• Which user owns /app in your scenario and which user executes the container?

root@8fa68f8db769:/app# ls -lah /app
total 100K
drwxrwxr-x 11 1000 1000 4.0K Oct 11 11:09 .
drwxr-xr-x  1 root root 4.0K Oct 11 11:09 ..
-rw-rw-r--  1 1000 1000   11 Aug 30 12:33 .dockerignore
drwxrwxr-x  8 1000 1000 4.0K Oct 11 10:12 .git
-rw-rw-r--  1 1000 1000   89 Sep 23 09:33 .git-blame-ignore-revs
-rw-rw-r--  1 1000 1000  134 Oct 11 10:07 .pre-commit-config.yaml
-rw-rw-r--  1 1000 1000  815 Jul  5 12:16 .project
-rw-rw-r--  1 1000 1000  12K Oct 11 10:06 CMakeLists.txt
-rw-rw-r--  1 1000 1000 1.6K Oct 11 10:06 Dockerfile
-rw-rw-r--  1 1000 1000  211 Oct 11 10:10 README.md

• Are you making use of the --user flag?
  • No, should I?
• Do you run Docker rootless or do you use a docker replacement?
  • Docker daemon is running as root, but I'm part of the docker group.
• What is the output of git version --build-option both on your box and inside the container

root@8fa68f8db769:/app# git --version
git version 2.39.2

me $ git --version
git version 2.43.0

• Docker version could be useful, too.

$ docker --version
Docker version 24.0.7, build 24.0.7-0ubuntu4.1

[ktomk]

• Which user owns /app in your scenario and which user executes the container?

same here.

• Are you making use of the --user flag?

  • No, should I?

Perhaps. --user=0:0 --deploy mount worked in my tests, however --user=0:0 --deploy copy not.

This is likely a bug and I hacked it in, a build is running: https://github.com/ktomk/pipelines/actions/runs/11297024415

It comes with the price that only numeric UID / GID make sense as it is not consulting the daemon to obtain an owner or group mapping.

fix(issue-30): use uid/gid from --user with --deploy copy

during pipelines --deploy copy respect a --user <uid>[:gid] by
adding tar flags --numeric-owner --owner=:<uid> [--group=:<gid>] to
the tar creations.

and the tar version must support those flags. on your system this should not be any issue.

• Do you run Docker rootless or do you use a docker replacement?

  • Docker daemon is running as root, but I'm part of the docker group.

Then I think adding --user support for --deploy copy is preferable, because this means that if anything gets written with --deploy mount it's with the container user, e.g. root into .git/ can cause some surprises if not short moments of shocks.

One of the reasons why the error message in the first place.

Consider switching to Docker Rootless if you are using Docker for development.

The change is early, but perhaps you may want to give it a try.