GitLab support #72

Open WhyNotHugo opened 3 years ago

Hi! Is GitLab support on your backlog?

Is there any way to contribute to help that happen?

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

the installation parts are

We do the installation like this:

User adds a webhook in the project settings.
On the first call, we send the user a (per-project and per-namespace) token generated by jwt in a form of a confidential issue.
User set this token in the webhook settings.
On the other calls, the token is checked. (When decrypted, it contains project/namespace URL.)
We request the needed permissions for our user on the fly.

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.

the repository parts aren't the tricky part

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.

User adds a webhook in the project settings.

On the first call, we send the user a (per-project and per-namespace) token generated by jwt in a form of a confidential issue.

Why do you have to do this, instead of giving them a unique webhook in the first place?

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 pre-commit.ci does but using GitLab's scheduled pipelines. This is what I have:

$ cat ci/pre-commit-update.sh
#!/bin/bash
set -ex
pre-commit autoupdate
git status
git diff --quiet -- .pre-commit-config.yaml && git diff --staged --quiet -- .pre-commit-config.yaml || exit_code=$?

if [[ ${exit_code} -ne 0 ]]; then
  PRE_COMMIT_CI_BRANCH="pre-commit-ci-update-config-$(date +'%Y%m%d')"

  git config --global user.email "git@gitlab.cern.ch"
  git config --global user.name "GitLab CI"
  git remote set-url origin "https://__pre-commit_ci_token:${PRE_COMMIT_CI_JOB_TOKEN}@${CI_SERVER_HOST}:${CI_SERVER_PORT}/${CI_PROJECT_PATH}.git"
  git remote -v
  git add .pre-commit-config.yaml
  git checkout -b "${PRE_COMMIT_CI_BRANCH}"
  git commit -m "chore: [pre-commit.ci] pre-commit autoupdate"
  git push -u origin "${PRE_COMMIT_CI_BRANCH}":"${PRE_COMMIT_CI_BRANCH}" \
           -o merge_request.create \
           -o merge_request.target="$CI_DEFAULT_BRANCH" \
           -o merge_request.merge_when_pipeline_succeeds \
           -o merge_request.remove_source_branch \
           -o merge_request.title="chore: [pre-commit.ci] pre-commit autoupdate"
fi

You need to use a PAT ([Project or Personal] Access Token) with write_repository permissions and add that as a CI/CD variable called PRE_COMMIT_CI_JOB_TOKEN. The .gitlab-ci.yml looks like (I added stages so you understand the ordering)

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:

ignores the .pre-commit-config.yaml configuration for autoupdating (you schedule your pipeline in the project settings)
merge request description won't be filled out with changes (you'll have to just look at the MR and view the changes manually.. I know)
I used push options (the -o flag) to set the MR to automerge (but maybe this is not your style and that's a line you can remove in the script).

pre-commit-ci / issues

GitLab support #72