diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2021-06-08 21:10:23 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2021-06-08 21:10:23 +0300 |
commit | 8a03b5424b73679d852fbf43781d9422c83869f7 (patch) | |
tree | a24a9c56fce9530492d60a640572922dd65d1072 /doc/development/cicd | |
parent | 0ebbf19f2d2b87e1f2aca1c59efde1aa6a766cf6 (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc/development/cicd')
-rw-r--r-- | doc/development/cicd/index.md | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/doc/development/cicd/index.md b/doc/development/cicd/index.md index 6a51feba650..025d63f4a62 100644 --- a/doc/development/cicd/index.md +++ b/doc/development/cicd/index.md @@ -67,7 +67,7 @@ The communication between runners and the Rails server occurs through a set of A the `Runner API Gateway`. We can register, delete, and verify runners, which also causes read/write queries to the database. After a runner is connected, -it keeps asking for the next job to execute. This invokes the [`RegisterJobService`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/ci/register_job_service.rb) +it keeps asking for the next job to execute. This invokes the [`RegisterJobService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/register_job_service.rb) which picks the next job and assigns it to the runner. At this point the job transitions to a `running` state, which again triggers `ProcessPipelineService` due to the status change. For more details read [Job scheduling](#job-scheduling)). @@ -103,7 +103,7 @@ A job with the `created` state isn't seen by the runner yet. To make it possible When the runner is connected, it requests the next `pending` job to run by polling the server continuously. NOTE: -API endpoints used by the runner to interact with GitLab are defined in [`lib/api/ci/runner.rb`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/ci/runner.rb) +API endpoints used by the runner to interact with GitLab are defined in [`lib/api/ci/runner.rb`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/api/ci/runner.rb) After the server receives the request it selects a `pending` job based on the [`Ci::RegisterJobService` algorithm](#ciregisterjobservice), then assigns and sends the job to the runner. @@ -121,7 +121,7 @@ Once the runner is [registered](https://docs.gitlab.com/runner/register/) using The runner initiates the communication by requesting jobs to execute with `POST /api/v4/jobs/request`. Although this polling generally happens every few seconds we leverage caching via HTTP headers to reduce the server-side work load if the job queue doesn't change. -This API endpoint runs [`Ci::RegisterJobService`](https://gitlab.com/gitlab-org/gitlab/blob/master/app/services/ci/register_job_service.rb), which: +This API endpoint runs [`Ci::RegisterJobService`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/services/ci/register_job_service.rb), which: 1. Picks the next job to run from the pool of `pending` jobs 1. Assigns it to the runner |