Enable ci_needs_optional by default
What does this MR do?
This MR enables ci_needs_optional
by default.
It's enabled on GitLab.com
=> #323891 (comment 538462483)
- Feature issue: #30680 (closed)
- Introduced in: !55468 (merged)
- FF rollout issue: #323891 (closed)
Does this MR meet the acceptance criteria?
Conformity
-
📋 Does this MR need a changelog?-
I have included a changelog entry. -
I have not included a changelog entry because I accidentally added a changelog in the first MR.
-
-
Documentation (if required) -
Code review guidelines -
Merge request performance guidelines -
Style guides -
Database guides -
Separation of EE specific content
Availability and Testing
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. -
Tested in all supported browsers -
Informed Infrastructure department of a default or new setting change, if applicable per definition of done
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 %14.0
added backend devopsverify documentation feature flag grouppipeline authoring sectionops typefeature typemaintenance + 1 deleted label
2 Messages 📖 CHANGELOG missing: If you want to create a changelog entry for GitLab FOSS, run the following:
bin/changelog -m 57560 "Enable ci_needs_optional by default"
If you want to create a changelog entry for GitLab EE, run the following instead:
bin/changelog --ee -m 57560 "Enable ci_needs_optional by default"
If this merge request doesn't need a CHANGELOG entry, feel free to ignore this message.
📖 This merge request adds or changes documentation files. A review from the Technical Writing team before you merge is recommended. Reviews can happen after you merge. 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:
-
Metadata for the
*.md
files that you've changed. The first few lines of each*.md
file identify the stage and group most closely associated with your docs change. - The Technical Writer assigned for that stage and group.
- Documentation workflows for information on when to assign a merge request for review.
If needed, you can retry the
danger-review
job that generated this comment.Generated by
🚫 DangerEdited by 🤖 GitLab Bot 🤖changed milestone to %13.11
- Resolved by Furkan Ayhan
- Resolved by Furkan Ayhan
@marcel.amirault Can you please do the documentation review?
assigned to @marcel.amirault
requested review from @marcel.amirault
- Resolved by Furkan Ayhan
unassigned @marcel.amirault
removed review request for @marcel.amirault
@reprazent Roulette did not work for this MR so I directly selected a maintainer from GitLab Review Workload Dashboard. I think we can assign this kind of MRs directly to maintainers
🤔 Edited by Furkan Ayhanassigned to @reprazent
requested review from @reprazent
I think we can assign this kind of MRs directly to maintainers
🤔 @furkanayhan Yep, that's fine!
The last pipeline completed less than an hour ago. Merging manually.
mentioned in commit ae3776b8
mentioned in issue gitlab-com/gl-infra/scalability#958
added workflowstaging label
added workflowcanary label and removed workflowstaging label
added workflowproduction label and removed workflowcanary label
added releasedcandidate label
removed typefeature label
added Category:Pipeline Composition label