Previously `ProjectCacheWorker` would be scheduled once per ref, which
would generate unnecessary I/O and load on Sidekiq, especially if many
tags or branches were pushed at once. `ProjectCacheWorker` would expire
three items:
1. Repository size: This only needs to be updated once per push.
2. Commit count: This only needs to be updated if the default branch
is updated.
3. Project method caches: This only needs to be updated if the default
branch changes, but only if certain files change (e.g. README,
CHANGELOG, etc.).
Because the third item requires looking at the actual changes in the
commit deltas, we schedule one `ProjectCacheWorker` to handle the first
two cases, and schedule a separate `ProjectCacheWorker` for the third
case if it is needed. As a result, this brings down the number of
`ProjectCacheWorker` jobs from N to 2.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/52046
Previously each tag in a push would invoke the Gitaly `FindAllTags` RPC
since the tag cache would be invalidated with every tag.
We can eliminate those extraneous calls by expiring the tag cache once
in `PostReceive` and taking advantage of the cached tags.
Relates to https://gitlab.com/gitlab-org/gitlab-ce/issues/65795
Whenever `PostReceive` is enqueued, `UpdateMergeRequestsWorker`
is enqueued and `MergeRequests::RefreshService` is called, it'll
check if the source branch of each MR asssociated to the push exists
or not via `MergeRequest#source_branch_exists?`. The said method will
call `Repository#branch_exists?` which is cached in `Rails.cache`.
When the cache contains outdated data and the source branch actually
exists, the `MergeRequests#RefreshService` job will close associated
MRs which is not correct.
The fix is to expire the branches cache of the project so we have
updated data during the post receive hook which will help in the
accuracy of the check if we need to close associated MRs or not.
Previously the raw push option Array was sent to Pipeline::Chain::Skip.
This commit updates this class (and the chain of classes that pass the
push option parameters from the API internal `post_receive` endpoint to
that class) to treat push options as a Hash of options parsed by
GitLab::PushOptions.
The GitLab::PushOptions class takes options like this:
-o ci.skip -o merge_request.create -o merge_request.target=branch
and turns them into a Hash like this:
{
ci: {
skip: true
},
merge_request: {
create: true,
target: 'branch'
}
}
This now how Pipeline::Chain::Skip is determining if the `ci.skip` push
option was used.
gitlab-org/gitlab-shell!166 added support for collecting push options
from the environment, and passing them along to the
/internal/post_receive API endpoint.
This change handles the new push_options JSON element in the payload,
and passes them on through to the GitPushService and GitTagPushService
services.
Futhermore, it adds support for the first push option, ci.skip. With
this change, one can use 'git push -o ci.skip' to skip CI pipe
execution. Note that the pipeline is still created, but in the "skipped"
state, just like with the 'ci skip' commit message text.
Implements #18667
Before we would need to identify a user when pushing
through the GitLab UI. Since this is no longer the case
we can remove the identification by commit and instead,
use the identify_using_user
When Gitlab::GitPostReceive#changes_refs is empty
user would not get defined and nil would be passed
to PostReceive#after_project_changes_hooks which would
then throw an error.
2018-10-25 11:23:34 +01:00
Francisco Javier López 🌴 (About to) On vacation; back on August 22th!
The change to base64-encoding the third argument to PostReceive in
gitlab-shell made our Sidekiq ArgumentsLogger a little less useful.
This change adds a log statement for the decoded data.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/20381
GitLab Bot