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

GitHub Pull Request does not work when using a fine-grained access token #13293

Open
2 tasks done
Earthcomputer opened this issue Dec 14, 2024 · 8 comments
Open
2 tasks done

Comments

@Earthcomputer
Copy link

Describe the issue

When I am using a self-hosted instance of Weblate to create a pull request (via a fork), the log is printing:

weblate_1   | gunicorn stderr | [2024-12-14 14:56:26,093: WARNING/422] git: Creating pull request via https://api.github.com/repos/Earthcomputer/clientcommands/pulls failed (403): {'message': 'Resource not accessible by personal access token', 'documentation_url': 'https://docs.github.com/rest/pulls/pulls#create-a-pull-request', 'status': '403'}

I already tried

  • I've read and searched the documentation.
  • I've searched for similar filed issues in this repository.

Steps to reproduce the behavior

  1. Create a fine-grained PAT on GitHub with the necessary read and write permissions (administration, code, and pull requests) (the first of these is required to make a fork which is not listed in the documentation but that's a separate issue).
  2. Set the GITHUB_CREDENTIALS as specified in the documentation
  3. Link up a repository to GitHub (pull requests mode), leave the push URL and push branch blank as directed in the docs so that it creates a fork.
  4. Change some translations, commit them, and try to push them

Expected behavior

The pull request is created successfully

Screenshots

image

Exception traceback

No response

How do you run Weblate?

Docker container

Weblate versions

  • Weblate: 5.8.4
  • Django: 5.1.3
  • siphashc: 2.5
  • translate-toolkit: 3.14.1
  • lxml: 5.3.0
  • pillow: 11.0.0
  • nh3: 0.2.18
  • python-dateutil: 2.9.0.post0
  • social-auth-core: 4.5.4
  • social-auth-app-django: 5.4.2
  • django-crispy-forms: 2.3
  • oauthlib: 3.2.2
  • django-compressor: 4.5.1
  • djangorestframework: 3.15.2
  • django-filter: 24.3
  • django-appconf: 1.0.6
  • user-agents: 2.2.0
  • filelock: 3.16.1
  • RapidFuzz: 3.10.1
  • openpyxl: 3.1.5
  • celery: 5.4.0
  • django-celery-beat: 2.7.0
  • kombu: 5.4.2
  • translation-finder: 2.19
  • weblate-language-data: 2024.14
  • html2text: 2024.2.26
  • pycairo: 1.27.0
  • PyGObject: 3.50.0
  • diff-match-patch: 20241021
  • requests: 2.32.3
  • django-redis: 5.4.0
  • hiredis: 3.0.0
  • sentry-sdk: 2.18.0
  • Cython: 3.0.11
  • mistletoe: 1.4.0
  • GitPython: 3.1.43
  • borgbackup: 1.4.0
  • pyparsing: 3.2.0
  • ahocorasick_rs: 0.22.1
  • python-redis-lock: 4.0.0
  • charset-normalizer: 3.4.0
  • cyrtranslit: 1.1.1
  • drf-spectacular: 0.27.2
  • Python: 3.12.7
  • Git: 2.39.5
  • psycopg: 3.2.3
  • psycopg-binary: 3.2.3
  • phply: 1.2.6
  • ruamel.yaml: 0.18.6
  • tesserocr: 2.7.1
  • boto3: 1.35.65
  • aeidon: 1.15
  • iniparse: 0.5
  • mysqlclient: 2.2.6
  • google-cloud-translate: 3.18.0
  • openai: 1.54.5
  • Mercurial: 6.8.2
  • git-svn: 2.39.5
  • git-review: 2.4.0
  • PostgreSQL server: 17.2
  • Database backends: django.db.backends.postgresql
  • PostgreSQL implementation: psycopg3 (binary)
  • Cache backends: default:RedisCache, avatar:FileBasedCache
  • Email setup: django.core.mail.backends.smtp.EmailBackend: smtp.eu.mailgun.org
  • OS encoding: filesystem=utf-8, default=utf-8
  • Celery: redis://cache:6379/1, redis://cache:6379/1, regular
  • Platform: Linux 5.15.0-117-generic (x86_64)

Weblate deploy checks

WARN[0000] /srv/weblate/docker-compose.override.yml: the attribute `version` is obsolete, it will be ignored, please remove it to avoid potential confusion 
System check identified some issues:

WARNINGS:
?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems.
?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS.
?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions.

INFOS:
?: (weblate.I021) Error collection is not set up, it is highly recommended for production use
        HINT: https://docs.weblate.org/en/weblate-5.8.4/admin/install.html#collecting-errors
?: (weblate.I028) Backups are not configured, it is highly recommended for production use
        HINT: https://docs.weblate.org/en/weblate-5.8.4/admin/backup.html

System check identified 5 issues (12 silenced).

Additional context

I think this might be on GitHub's end but I'm not sure, maybe the permissions have changed.

@nijel
Copy link
Member

nijel commented Dec 16, 2024

Thanks for the feedback, I've clarified the permissions needed in 6a60520.

As for creating the pull requests, I know this works for many of our customers, so it might also be something in the repository configuration. Do you have any specific branch rules that might prohibit this?

@Earthcomputer
Copy link
Author

There are branch protection rules in the upstream repository, but not in the fork where Weblate is pushing to. In fact, the pushing is succeeding, but the pull requesting is failing.

image
image
image

It must be something to do with the fine-grained tokens because I have temporarily switched to classical tokens and it's working

@nijel
Copy link
Member

nijel commented Dec 16, 2024

The pull request goes to the upstream repository, does Weblate have the pull request permission there?

@Earthcomputer
Copy link
Author

I'm a bit confused, anybody on GitHub can make a PR to the upstream repository, as it's a public user (non-organization) repository, so surely it shouldn't require any special permissions?

The REST API docs state that:

To open or update a pull request in a public repository, you must have write access to the head or the source branch.

The bot account has write access to the source branch.

@Earthcomputer
Copy link
Author

Are you at least able to reproduce the issue using the steps provided? You can use my repository (https://github.com/Earthcomputer/clientcommands) if you like

@nijel
Copy link
Member

nijel commented Dec 19, 2024

Based on https://docs.github.com/rest/pulls/pulls#create-a-pull-request you need "Pull requests" repository permissions (write) permission on the target repository to create a pull request. So it won't work if you only have fine-grained token with permissions only to the cloned repository. The fine-grained tokens can be confusing in this, but you need to grant it access to both repositories to make it work in the fork/pull request workflow.

@Earthcomputer
Copy link
Author

I don't see where in those docs it specifies that, but it would definitely explain the problem if that were the case. It's a very strange requirement given that you can create pull requests without permission from the target repository using classical tokens (or indeed via the UI). I will try and find out how to grant this permission tomorrow, but I would definitely consider this a defect on GitHub's side if it is necessary, as it really doesn't make sense

@nijel
Copy link
Member

nijel commented Dec 20, 2024

It kind of makes sense, the fine-grained token is there to explicitly define the scope where the token can be used. But at the same time, it is confusing as pull request on public repository is something people expect to work. Still, I'm just describing what I observe and I might be wrong.

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

No branches or pull requests

3 participants
@nijel @Earthcomputer and others