summaryrefslogtreecommitdiff
path: root/lib/gitlab/git_post_receive.rb
Commit message (Collapse)AuthorAgeFilesLines
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2020-03-051-5/+5
|
* Add latest changes from gitlab-org/gitlab@masterGitLab Bot2019-10-031-23/+20
|
* Expire project caches once per push instead of once per refStan Hu2019-08-161-0/+11
| | | | | | | | | | | | | | | | | | | | | | 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
* Only expire tag cache once per pushsh-only-flush-tags-once-per-pushStan Hu2019-08-131-0/+6
| | | | | | | | | | 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
* Rename branches_exist? -> includes_branches?65803-invalidate-branches-cache-on-refreshStan Hu2019-08-091-5/+3
|
* Invalidate branches cache on PostReceivePatrick Bajao2019-08-091-0/+8
| | | | | | | | | | | | | | | | 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.
* Use Gitlab::PushOptions for `ci.skip` push optionLuke Duncalfe2019-04-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Add support for Git push options, specifically ci.skipJonathon Reinhart2018-12-311-2/+3
| | | | | | | | | | | | | | | | | 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
* Removes idenfitication by commit from Gitlab::Identifier51335-fail-early-when-user-cannot-be-identifiedTiago Botelho2018-10-251-2/+2
| | | | | | | 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
* User not defined in PostReceive#process_project_changesTiago Botelho2018-10-251-1/+1
| | | | | | | 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.
* Code cleaning in PostReceive servicesFrancisco Javier López 🌴 (About to) On vacation; back on August 22th!2018-07-311-6/+6
|
* Added repository_update hookGabriel Mazetto2017-05-121-0/+10
|
* Allow gl-repository strings as project identifiers in PostReceive workerAlejandro Rodríguez2017-05-051-26/+3
|
* replace `find_with_namespace` with `find_by_full_path`Adam Pahlevi2017-02-031-2/+2
| | | | add complete changelog for !8949
* Log base64-decoded PostReceive argumentsJacob Vosmaer2016-08-051-1/+0
| | | | | | | | 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
* Back-porting PostReceive refactor made for EE 🍺Gabriel Mazetto2016-03-171-0/+60