Process at most 4 pipelines during push
What does this MR do?
This limits the number of pipelines that we create in a single push to 4.
This is to prevent doing git push --all
or git push --mirror
to create a ton of Pipelines.
This does not prevent every possible abusive scenario, but rather prevent mistakes when dealing with git repository.
Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/51401
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry -
Documentation created/updated or follow-up review issue created -
Code review guidelines -
Style guides
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods -
Security reports checked/validated by a reviewer from the AppSec team
Merge request reports
Activity
changed milestone to %12.0
added Deliverable bugavailability devopsverify missed-deliverable missed:11.6 missed:11.7 priority2 security severity2 typebug + 1 deleted label
removed missed-deliverable missed:11.6 missed:11.7 security labels
added 85 commits
-
fcc2cdce...e861af40 - 84 commits from branch
master
- 7ffb7d7a - Process at most 4 pipelines during push
-
fcc2cdce...e861af40 - 84 commits from branch
changed milestone to %11.11
- Resolved by Bob Van Landuyt
Maybe we should also ~"Pick into 11.10" ?
- Resolved by Grzegorz Bizon
I don't see strong reason why we try to process and create pipelines for all changes. In most cases you push a small number, like 1-2 to remote and this makes this behavior to work as-is. This prevents a for example doing
git push --all
or--tags
to have ~availability factor.
assigned to @smcgivern
assigned to @reprazent
@reprazent Please assign then to @smcgivern.
- Resolved by Kamil Trzciński
- Resolved by Kamil Trzciński
- Resolved by Kamil Trzciński
- Resolved by Bob Van Landuyt
@ayufan 2 ideas.
assigned to @ayufan
added feature flag + 1 deleted label
1 Warning This merge request is missing the ~Documentation label. 1 Message This merge request adds or changes files that require a review from the Technical Writing team. Documentation review
The following files require a review from a technical writer:
doc/ci/yaml/README.md
The review does not need to block merging this merge request. See the:
- DevOps stages for the appropriate technical writer for this review.
- Documentation workflows for information on when to assign a merge request for review.
Reviewer roulette
Changes that require review have been detected! A merge request is normally reviewed by both a reviewer and a maintainer in its primary category (e.g. frontend or backend), and by a maintainer in all other categories.
To spread load more evenly across eligible reviewers, Danger has randomly picked a candidate for each review slot. Feel free to override this selection if you think someone else would be better-suited, or the chosen person is unavailable.
Once you've decided who will review this merge request, mention them as you normally would! Danger does not (yet?) automatically notify them for you.
Category Reviewer Maintainer backend Peter Leitzen ( @splattael
)Stan Hu ( @stanhu
)~Documentation Achilleas Pipinellis ( @axil
)Generated by
DangerEdited by 🤖 GitLab Bot 🤖- Resolved by Grzegorz Bizon
- Resolved by Kamil Trzciński
assigned to @reprazent
mentioned in issue #51401 (closed)
- Resolved by Bob Van Landuyt
@grzesiek as you're already here, and there's some unresolved discussions you're involved in, would you mind taking the maintainer review?
assigned to @grzesiek
assigned to @brendan
assigned to @ayufan
assigned to @grzesiek
marked the checklist item Changelog entry as completed
marked the checklist item Documentation created/updated or follow-up review issue created as completed
marked the checklist item Code review guidelines as completed
marked the checklist item Style guides as completed
mentioned in commit a97e039e
changed milestone to %11.10
mentioned in merge request gitlab-com/www-gitlab-com!21184 (merged)
mentioned in merge request !27289 (merged)
mentioned in commit f3d1e553
mentioned in merge request !27308 (merged)
Picked into 11.10 for RC7 with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27308
mentioned in issue gitlab-org/release/tasks#750 (closed)
mentioned in issue gitlab-com/www-gitlab-com#3350 (closed)
mentioned in issue gitlab-org/release/tasks#778 (closed)
If this cannot be reverted, ca we at least:
A. Queue the pipelines and create them 4 at a time
OR
B. Make this configurable. Right now it's hardcoded ?!
Edited by Mircea Danila Dumitrescumentioned in issue gitlab#352365 (closed)
mentioned in issue gitlab#350886
mentioned in merge request gitlab!81974 (merged)
mentioned in issue gitlab-org/quality/triage-reports#15276 (closed)
mentioned in issue gitlab-org/quality/triage-reports#15703 (closed)
mentioned in issue gitlab-org/quality/triage-reports#16009 (closed)
mentioned in issue gitlab-org/quality/triage-reports#16471 (closed)
mentioned in issue gitlab-org/quality/triage-reports#17005 (closed)
mentioned in issue gitlab-org/quality/triage-reports#17455 (closed)
mentioned in issue gitlab-org/quality/triage-reports#17915 (closed)
mentioned in issue gitlab-org/quality/triage-reports#18448 (closed)
mentioned in issue gitlab-org/quality/triage-reports#18928 (closed)
mentioned in issue gitlab-org/quality/triage-reports#19382 (closed)
mentioned in issue gitlab-org/quality/triage-reports#20613 (closed)
mentioned in issue gitlab-org/quality/triage-reports#20978 (closed)
mentioned in issue gitlab-org/quality/triage-reports#21525 (closed)
mentioned in issue gitlab-org/quality/triage-reports#22029