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
GitLab support #72
Comments
it's eventually planned but not at all a priority at the moment. the backend is designed to support as many VCS services as possible, though I need to understand more how gitlab functions |
If you are interested, our service supports both GitHub and GitLab and we've created a library to have one Python API for all the git forges. The library does not help with everything because sometimes approaches of GitHub and GitLab differs a lot but might be handy to interact with the repository in a forge-independent way. Note that there is nothing like a GitHub application on GitLab and you need to do the installation/authentication yourself. |
the repository parts aren't the tricky parts -- the installation parts are |
We do the installation like this:
Not so elegant as on GitHub but works well so far. Since you have authenticated webpage, you might be able to set this up for users via API. Sadly, the Gitlab services concept does not help with this at all.
Sometimes they are. E.g. you can't set a commit status for merge-request created from fork if you don't have permissions for the fork repo. What is really annoying. |
Why do you have to do this, instead of giving them a unique webhook in the first place? |
I probably didn't make that clear, but that process is automated and we don't want to do any manual steps. So, the webhook is publically known and only the token is generated and made available to the project maintainers. Unique per-project webhook is like a secret and still needs to be somehow generated and provided to the right user and no one else. We haven't found any better way how the project owner can set up a webhook without us, make the webhooks secure and avoid calculating/reusing/leaking of the token by anyone without access to the project. That doesn't mean there is no simpler solution. I would be really glad to hear about any better alternative..;) |
Hi, in the meantime, I wanted to document my equivalent/rough attempt at emulating what
You need to use a PAT ([Project or Personal] Access Token) with stages:
- autoupdate
- check
- test
- build
- deploy
pre-commit-autoupdate:
stage: autoupdate
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
when: always
- if:
$CI_PIPELINE_SOURCE == "push" && $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
when: manual
# manual jobs need allow_failure? https://gitlab.com/gitlab-org/gitlab/-/issues/233876
allow_failure: true
script:
- python -m pip install pre-commit
- python -m pip freeze --local
- ci/pre-commit-update.sh Once you have all of this, you can set up a scheduled pipeline to run weekly and that should give you almost exactly the same functionality that pre-commit.ci is giving you for GitHub. The only differences right now:
|
Hi! Is GitLab support on your backlog?
Is there any way to contribute to help that happen?
The text was updated successfully, but these errors were encountered: