Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/31741 introduced
a regression where not all the right parameters would be passed into
`Ci::CreatePipelineService`. We fix this by breaking out the pipeline
parameters and reusing a method from `Gitlab::DataBuilder::Push`.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/66196
|
|
This commit reduces I/O load and memory utilization during PostReceive
for the common case when no project hooks or services are set up.
We saw a Gitaly N+1 issue in `CommitDelta` when many tags or branches
are pushed. We can reduce this overhead in the common case because we
observe that most new projects do not have any Web hooks or services,
especially when they are first created. Previously, `BaseHooksService`
unconditionally iterated through the last 20 commits of each ref to
build the `push_data` structure. The `push_data` structured was used in
numerous places:
1. Building the push payload in `EventCreateService`
2. Creating a CI pipeline
3. Executing project Web or system hooks
4. Executing project services
5. As the return value of `BaseHooksService#execute`
6. `BranchHooksService#invalidated_file_types`
We only need to generate the full `push_data` for items 3, 4, and 6.
Item 1: `EventCreateService` only needs the last commit and doesn't
actually need the commit deltas.
Item 2: In addition, `Ci::CreatePipelineService` only needed a subset of
the parameters.
Item 5: The return value of `BaseHooksService#execute` also wasn't being
used anywhere.
Item 6: This is only used when pushing to the default branch, so if
many tags are pushed we can save significant I/O here.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/65878
Fic
|
|
|
|
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.
|
|
Fixes #54721
|
|
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
|
|
Enables frozens string for the following:
* lib/gitlab/conflict/**/*.rb
* lib/gitlab/cross_project_access/**/*.rb
* lib/gitlab/cycle_analytics/**/*.rb
* lib/gitlab/data_builder/**/*.rb
* lib/gitlab/database/**/*.rb
* lib/gitlab/dependency_linker/**/*.rb
* lib/gitlab/diff/**/*.rb
* lib/gitlab/downtime_check/**/*.rb
* lib/gitlab/email/**/*.rb
* lib/gitlab/etag_caching/**/*.rb
Partially addresses gitlab-org/gitlab-ce#47424.
|
|
|
|
|
|
|
|
The change in !11728 would cause an arbitrary project to be chosen to test
system hooks, and it's likely that the project would not have any commits or
relevant commits to test the hook. This would prevent admins from verifying
that the hook fired. Instead of trying to create a representative hook
dynamically, just send static data to guarantee the hook will actually be
tested.
Closes #37067
|
|
|
|
|
|
add username field to push webhook
Closes #32136
See merge request !11272
|
|
Signed-off-by: David Turner <novalis@novalis.org>
|
|
|
|
When we updated gitlab_git to 10.4.1, `tag.target` changed from pointing
to the sha of the tag to the sha of the commit the tag points to. The
problem is that only annotated tags have `object_sha`s, lightweight tags
don't (it's nil), so (only) in their case we still need to use
`tag.target`.
|
|
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5620#note_13671791
|