Changelog: changed
EE: true

- the applying of a template creates a repository, which we map
  to git_write in learn gitlab. So we should ensure it is
  marked as completed when a project is created with a template.

This syncs changing the state from opened to closed for epic work items
to the legacy epic when the feature flag is enabled.

It's a scaffold for product usage activity tracking
for GitLab early access program. Only for participants
of the program and only who agreed on optional tracking.

Changelog: added

In https://gitlab.com/gitlab-org/gitlab/-/merge_requests/144638, we
introduced a bug due to which we started masking the parent group
members from the subgroup members when the visibility of these groups
were private.

To check if the member is from an ancestor we should check whether the
current source contains the member's source ID in its traversal IDs but
we were doing the opposite. The specs had a gap because we were only
testing public groups there and this problem only occurred for private
groups.

I have also added a feature spec to cover this case.

Changelog: fixed

Gitaly's transaction support is being rolled out. Prior to the roll
out, we want to exercise the transaction support in Rails pipeline.

Transactions introduce partitioning to Gitaly. Transactions aren't
allowed to do cross-partition operations on the file system. Object
pooling involves the file system level operations against the other
repositories in the same fork network. They need to be thus in the
same partition for the operations to work. Gitaly automatically
places the object pool and the forks in the same partition with the
origin repository as long as they are created using CreateObjectPool
and CreateFork. Rails specs are not doing this currently everywhere
which leads to test failures due to the specs attempting to do
cross-partition operations.

Update the specs to use CreateObjectPool and CreateFork where needed.

If the param is true and commit signing is enabled, then
the resulting commit will be signed. Default value is true
because we want the commits to be signed when commit signing
is enabled.

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/456986

**Problem**

Squash operation sends an empty message to in `UserSquashRequest` to
Gitaly. It leads to empty `CommitMessage` error.

**Solution**

Ensure that the message is always set.

Changelog: fixed

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/452488

**Problem**

https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6590 introduced a
bug that was raising a `listing commits` error if the repository was
empty.

I fixed it by adding an error handler for this error.

**Solution**

This original bug was fixed on Gitaly side:
https://gitlab.com/gitlab-org/gitaly/-/merge_requests/6801. The Rails
patch is not necessary anymore.

Changelog: other

This was causing a `NoMethodError` on trigger pipelines. The fixes a
transient bug was introduced in
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149456, which is
part of the same development milestone, so we're not adding another
changelog entry.

See https://gitlab.com/gitlab-com/gl-infra/production/-/issues/17885

Changelog: deprecated

Changelog: removed

Pure specs refactoring

- Changing to positive logic for
  the attributes related to access levels
- Renaming the fields `push_protected_up_to_access_level` and
  `delete_protected_up_to_access_level` in order to
  apply a positive logic (instead of negative logic), i.e.
  https://gitlab.com/gitlab-org/gitlab/-/merge_requests/135969#note_1688854082
- Renaming the field `push_protected_up_to_access_level`
  is renamed to field `minimum_access_level_for_push`
- Renaming the field `delete_protected_up_to_access_level`
  is renamed to field `minimum_access_level_for_delete`

Changelog: other

We are now showing the invited group members on the shared group members
page behind the `webui_members_inherited_users` feature flag. We mask
the source of membership if the current user cannot access the invited
group. We missed an edge case here where the source of membership was
being masked if the user had access to the invited group through
inheritance. Now the source of membership is not masked if the user has
access to the invited group through its parent group membership.

Remove `add_all_ci_running_builds` and `remove_all_ci_running_builds`
feature flags.

Changelog: changed

We have some (windows) runners that return any exit code
Other runners will only return 0..255 exit codes

As windows exit codes might have useful information about the build
we'll store these codes

Changelog: fixed

- Moved Unique constraint validation to EE
- Applied review comments

EE: true
Changelog: added

When a previously detected Secret moves within the file, this commit
ensures to reuse the existing Secret Detection(SD) vulnerabilities from
the database instead of creating newly detected duplicate findings. This
is done with the help of tracking signature of the vulnerability generated
using 'rule_value' algorithm.

Refer: https://gitlab.com/gitlab-org/gitlab/-/issues/434096

Changelog: added
EE: true

Changelog: fixed
EE: true

Changelog: added

In the future, we might make a change to how we handle user request
parameters in a way that has unexpected and undesired consequence;
specifically mass assignment vulnerabilities. (There are currently
none known). These additional unit tests and/or explicit type-casts are
intended to defend against that future scenario.

For example: attempting to brute force a password by sending many
passwords in a single request for a single user should never work. Nor
should sending multiple OTP codes. The reason they _might_
inadvertently work is because Ruby / Rails often doesn't mind if you
send a string or an array of strings. For example:

```ruby
# POST /vulnerable?email=fake@attacker.com
> User.find_by(email: params[:email])
# User Load (3.4ms)  SELECT "users".* FROM "users" WHERE "users"."email" = 'fake@attacker.com' LIMIT 1
=> nil

# We expect email to be a string, but what if it's not?
# POST /vulnerable?email[]=fake@attacker.com&email[]=admin@example.com
> User.find_by(email: params[:email])
# User Load (1.6ms)  SELECT "users".* FROM "users" WHERE "users"."email" IN ('fake@attacker.com', 'admin@example.com')
=> #<User id:1 @root>
```

This work resolves https://gitlab.com/gitlab-org/gitlab/-/issues/442831+

The methodology was to look at authentication & authorization-related
controllers, and down into any Helpers/Services/etc that are called
or included.

Added new placeholder user_type, added Imports::SourceUser, and service
to create them from imported user attributes.

This defines static webhook payloads for snippets and labels. This means
as attributes are added to these models we do not automatically
include them in the webhook payload until we redefine their `#hook_attr`
methods to do so.

This is a best practice to avoid sending data that we do not expect in
future.

The changes are behind feature flags.

https://gitlab.com/gitlab-org/gitlab/-/issues/440384

This reverts merge request !149174

Now we have a common layout and frontend architecture between all Usage Quotas Pages: Group, Project, User Namespace.
Users can now benefit from viewing their Storage Usage Quotas even when using GitLab Community Edition

Changelog: changed

- See https://gitlab.com/gitlab-org/gitlab/-/issues/455158

- Add a test case for filter_items when filtering by external
- Refactor tests for filter_items

Contributes to: https://gitlab.com/gitlab-org/gitlab/-/issues/435623

This adds several migrations that add an imported column
to resources that will display an imported icon in the UI
if they are imported. The column is a smallint type that
will use an enum and default to 0. The default value 0
will indicate the resource was not imported. Any other
value will indicate the importer used (e.g. github,
bitbucket, etc.)

Changelog: added

For Service Ping

A new column in the merge_requests_closing_issues
table (closes_work_item) will indicate if the existence
of the record means that the work item must be closed
when the related MR is closed or not

This commit updates the Catalog::Resources::CreateService to fetch the
verification level from a resource's root namespace and save it with the
resource. It also updates the `verification_level` field on the Resource
model so it has the same values as the `verification_field` on
VerifiedNamespace

Changelog: changed
Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/455530

The self_and_descendant_ids method has an optimization which might
improve the performance in some cases.

Contributes to https://gitlab.com/gitlab-org/gitlab/-/issues/455515

**Problem**

Currently, push mirror creation logic is duplicated and inconsitent
between API and UI. Moreover, we rely on `Projects::UpdateService` to
make changes to push mirrors. It's error-prone and inconvenient to use
push mirrors.

**Solution**

* Extract common push mirror creation logic into
`RemoteMirrors::CreateService`
* Add a new value object `Attributes` to handle allowed attributes list

Changelog: other
EE: true

Pure specs refactoring

This method is not used anymore after the changes made for
https://gitlab.com/gitlab-org/gitlab/-/issues/26169.
This method was deprecated before in favor of
the `Project#has_ci_config_file?` method.

In git 2.43.0+, Gitaly will read from `HEAD:.gitattributes` instead of
`info/gitattributes`. So gRPCs that related to `info/attributes`
are being deprecated and removed.

In https://gitlab.com/gitlab-org/gitaly/-/issues/5348, we made changes
on Gitaly side to make ApplyGitattributes no-op.

As a result, copy_gitattributes method which wraps ApplyGitattributes
can be removed from Rails.