Skip to content
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

Git can't commit because of "dubious ownership" #352

Closed
bermeitinger-b opened this issue Mar 2, 2023 · 9 comments · Fixed by #356
Closed

Git can't commit because of "dubious ownership" #352

bermeitinger-b opened this issue Mar 2, 2023 · 9 comments · Fixed by #356

Comments

@bermeitinger-b
Copy link

I'm the maintainer for https://github.com/flathub/org.signal.Signal and we recently introduced the beta branch of Signal. From my understanding, we need an own Github action for the beta branch.
This worked until yesterday.

I guess the fedc container updated the git version and is now running git in an environment which is deemed "unsafe" by git.
You can see from the action log: https://github.com/flathub/org.signal.Signal/actions/runs/4313990291/jobs/7526468080

[...]
fatal: detected dubious ownership in repository at '/github/workspace'
[...]
subprocess.CalledProcessError: Command '['git', 'branch', '--show-current']' returned non-zero exit status 128.

This issue is also tracked for the actions/checkout #1169. There seems to be no nice solution and only a workaround by running

git config --global --add safe.directory /github/workspace

inside the container before committing changes.

@bermeitinger-b bermeitinger-b changed the title Git can't push because of "dubious ownership" Git can't commit because of "dubious ownership" Mar 2, 2023
@wjt
Copy link
Contributor

wjt commented Mar 2, 2023

What do you see for uid and stat /github/workspace (at the same point where you're adjusting the safeness of the directory)? This looks like the container is running as a different UID to the one that owns the clone.

@bermeitinger-b
Copy link
Author

The output of running id is uid=0(root) gid=0(root) groups=0(root)

@wjt
Copy link
Contributor

wjt commented Mar 2, 2023

Right, but who owns /github/workspace?

@bermeitinger-b
Copy link
Author

Sorry, the output of stat /github/workspace is:

   File: /github/workspace
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 811h/2065d	Inode: 1806381     Links: 4
Access: (0755/drwxr-xr-x)  Uid: ( 1001/ UNKNOWN)   Gid: (  123/ UNKNOWN)
Access: 2023-03-02 13:53:07.704985276 +0000
Modify: 2023-03-02 13:53:08.525034185 +0000
Change: 2023-03-02 13:53:08.525034185 +0000
 Birth: 2023-03-02 13:52:58.272422090 +0000

@bermeitinger-b
Copy link
Author

Current workaround is adding this:

      - uses: docker://ghcr.io/flathub/flatpak-external-data-checker:latest
        env:
          ...
        with:
          entrypoint: /bin/bash
          args: -c "git config --global --add safe.directory /github/workspace && cd /github/workspace && /app/flatpak-external-data-checker --update --never-fork org.signal.Signal.yaml"

rany2 added a commit to flathub/com.brave.Browser that referenced this issue Mar 2, 2023
rany2 added a commit to flathub/com.brave.Browser that referenced this issue Mar 2, 2023
dbnicholson added a commit to dbnicholson/flatpak-external-data-checker that referenced this issue Mar 9, 2023
When running the checker in a container containing a recent git, it will
often fail because the container user is not the same as the user owning
the repository. Register the checkout as a safe directory if it isn't
already.

Fixes: flathub-infra#352
dbnicholson added a commit to dbnicholson/flatpak-external-data-checker that referenced this issue Mar 9, 2023
When running the checker in a container containing a recent git, it will
often fail because the container user is not the same as the user owning
the repository. Register the checkout as a safe directory if it isn't
already.

Fixes: flathub-infra#352
dbnicholson added a commit to dbnicholson/flatpak-external-data-checker that referenced this issue Mar 9, 2023
When running the checker in a container containing a recent git, it will
often fail because the container user is not the same as the user owning
the repository. Register the checkout as a safe directory if it isn't
already.

Fixes: flathub-infra#352
@wjt wjt closed this as completed in #356 Mar 9, 2023
@dbnicholson
Copy link
Contributor

Hmm, #356 didn't work. I think I was too eager assuming that git config --get-all would only fail on older git that didn't know about safe.directory. In fact, it exits with code 1 if the key doesn't exist in the configuration. Let's try that again.

@dbnicholson
Copy link
Contributor

Now it really worked after #357.

@Salamandar
Copy link

Hello, I still have this issue today. Here's my workflow file:

name: Update Flatpak dependencies
on:
  # for scheduling to work this file must be in the default branch
  schedule:
  - cron: "17 0 * * MON"
  # can be manually dispatched under GitHub's "Actions" tab
  workflow_dispatch:


jobs:
  flatpak-external-data-checker:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        branch: [ main ] # list all branches to check

    steps:
      - uses: actions/checkout@v3
        with:
          ref: ${{ matrix.branch }}

      - uses: docker://ghcr.io/flathub/flatpak-external-data-checker:latest
        env:
          GIT_AUTHOR_NAME: Flatpak External Data Checker
          GIT_COMMITTER_NAME: Flatpak External Data Checker
          # email sets "github-actions[bot]" as commit author, see https://github.community/t/github-actions-bot-email-address/17204/6
          GIT_AUTHOR_EMAIL: 41898282+github-actions[bot]@users.noreply.github.com
          GIT_COMMITTER_EMAIL: 41898282+github-actions[bot]@users.noreply.github.com
          EMAIL: 41898282+github-actions[bot]@users.noreply.github.com
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          args: --update --never-fork packaging/flatpak/org.syncthing-gtk.syncthing-gtk.yml

Salamandar added a commit to syncthing-gtk/syncthing-gtk that referenced this issue Jun 7, 2023
@dbnicholson
Copy link
Contributor

          args: --update --never-fork packaging/flatpak/org.syncthing-gtk.syncthing-gtk.yml

I just ran into this same problem today. The fix I made before assumes that the manifest is in the root of the git checkout. Obviously, that's not always the case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants