Support several instance for API calls
What does this MR do and why?
This adds support to make API calls to different GitLab instances (for now we only support gitlab.com
and dev.gitlab.org
).
This is a prerequisite for #1380 (closed) where we'll need to fetch jobs from the dev
instance.
TODO
-
Populate GITLAB_COM_API_TOKEN
with the value ofGITLAB_API_TOKEN
-
For now, I populated GITLAB_DEV_API_TOKEN
with a personal token of mine, while we create a proper@gitlab-bot
service account ondev
-
Create a proper @gitlab-bot
service account ondev
and replace the value ofGITLAB_DEV_API_TOKEN
with a personal token from it
Expected impact & dry-runs
These are strongly recommended to assist reviewers and reduce the time to merge your change.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/tree/master/doc/scheduled#testing-policies-with-a-dry-run on how to perform dry-runs for new policies.
See https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/doc/reactive/best_practices.md#use-the-sandbox-to-test-new-processors on how to make sure a new processor can be tested.
Action items
-
If adding environment variables for reactive processors, update config/triage-web.yaml
and.gitlab/ci/triage-web.yml
-
(If applicable) Add documentation to the handbook pages for Triage Operations => - (If applicable) Identify the affected groups and how to communicate to them:
-
/cc @ person_or_group
=> -
Relevant Slack channels => -
Engineering week-in-review
-
Edited by Rémy Coutable