Taking GitLab repo description from GL_REPOSITORY
We make `GL_REPOSITORY` the norm to describe the repo in GitLab terms: - in `wsgi.py`, we now expect to receive it from Heptapod Workhorse, matching changes done there right after the merge with the version for GitLab 12.3.5. In the subprocess call case (gitlab-shell or Rails app), we already had it. - instead of hardcoding `project-$id` to pass it to GitLab API endpoints, which was too restrictive, we just repass it over - we still produce a `HEPTAPOD_PROJECT_ID` environment variable for external Mercurial hooks, but now we derive it from GL_REPOSITORY
parent
94c6158b3bfa
No related branches found
No related tags found
Checking pipeline status
Showing
- heptapod/gitlab/__init__.py 4 additions, 4 deletionsheptapod/gitlab/__init__.py
- heptapod/gitlab/tests/test_hooks_integration.py 7 additions, 7 deletionsheptapod/gitlab/tests/test_hooks_integration.py
- heptapod/tests/test_wsgi.py 5 additions, 1 deletionheptapod/tests/test_wsgi.py
- heptapod/wsgi.py 8 additions, 1 deletionheptapod/wsgi.py
Loading
Please register or sign in to comment