Brian Williams authored 2 years ago and Mayra Cabrera committed 2 years ago

This is part one of a multi-part implementation to support validation of
git commits signed by SSH keys. This adds the database tables and models
for SSH commit signatures, using the same pattern as the existing
gpg_signatures and x509_signatures tables. These will be used to show
the verification status on commits which are signed.

Changelog: added

Addressing Issue: https://gitlab.com/gitlab-org/gitlab/-/issues/362926

Updates ProjectAttributesPipeline to use the common JsonExtractor and
update spec files accordingly

Eduardo Sanz-Garcia authored 2 years ago and Marc Shaw committed 2 years ago

Because of the possible risk introduce in this MR, we are going to
conditional turn on/off this feature using the flag: `access_token_ajax`

See: https://gitlab.com/gitlab-org/gitlab/-/issues/359956
Complete plan: https://gitlab.com/gitlab-org/gitlab/-/issues/357848

Changelog: added

not a ConnectionExtension

that can live on the main code branch

It appears that each connection needs to be adopted. However,
in it's initial phase (before being adopted) the Rails
might execute SQL queries to configure the connection settings
(collation, timeouts, etc.). This will happen before
the connection is actually assigned to the connection pool,
as if such connection will be failed to be initialized
it will be orphaned.

Changelog: removed

Gitaly's UserCherryPick RPC will begin to return structured errors. The
reason is that currently we return an error message embedded in the
response and hence it looks like the RPC succeeded. This not only hides
errors in the metrics and logs, Praefect will also expect transaction
voting to happen correctly for successful requests. However, an error
happened which sometimes causes voting to not happen at all. In this
situation, Praefect will schedule unneeded replication jobs.

This change prepares for the Gitaly change by putting in place code that
parses the structured error and raises the same errors as it did when
parsing the response for the analagous errors.

Changelog: changed

The `with_restored_connection_stack` completely rewrites connection
stack. At least in case of `finalize_batched_background_migration`
we require to have a connection to pass lower layers. Making the
`with_*` to return connection allows us to pass re-mapped connection
that was previously set to `ActiveRecord::Base`.

This also tests the `#finalize_` that a correct connection stack is
used.

See merge request
https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87178

David Fernandez authored 2 years ago and Bob Van Landuyt :neckbeard: committed 2 years ago

Changelog: fixed

This makes `exec_insert_all` on a connection look like a write to the
loadbalancer. Causing subsequent queries to stick to the primary.

Both [upserts][0] and [inserts][1] use `ActiveRecord::InsertAll` to
build the query, which is then executed on the connection using
`#exec_insert_all` [2].

Because the connection proxy did not know about this method, it fell
back to the primary, but without causing the session to stick
there. This meant that any insert done there would not be found when
querying for it immediately after.

[0]: https://github.com/rails/rails/blob/66073335585f04f2ed0f5ef930eb3c8955d50a6a/activerecord/lib/active_record/persistence.rb#L243
[1]: https://github.com/rails/rails/blob/66073335585f04f2ed0f5ef930eb3c8955d50a6a/activerecord/lib/active_record/persistence.rb#L124
[2]: https://github.com/rails/rails/blob/66073335585f04f2ed0f5ef930eb3c8955d50a6a/activerecord/lib/active_record/insert_all.rb#L35

Extract ServicePing payload computation and persistance
out of SubmitService into GitlabServicePingWorker
in order to pre compute SerivcePing data for preview
for instance admins even if those instances does not submit
this data later on to GitLab

Changelog: performance

Uses the application settings value stored into
the `pipeline_limit_per_project_user_sha` column
to control the pipelines creation rate limit.

To enable the rate limit the value needs to be
greater than zero and the feature flag
`ci_enforce_throttle_pipelines_creation` has to be enabled.
Otherwise the rate limit will only log the pipelines that
are over the limit without preventing them from being created.

Changelog: other

Remove redundant namespaces from a base query when searching for
descendants.

Patrick Steinhardt authored 2 years ago and Sean Arnold committed 2 years ago

It was reported by users that custom hook errors aren't displayed in the
UI anymore. This issue has repeatedly come up in the last few years,
which is mostly because the calling convention was really bad: Gitaly
must return the standard error or standard output of custom hooks as the
error message without any modification, or otherwise it doesn't work.

To fix issues like this, Gitaly has introduced a new `CustomHookError`
detailed error message: if a custom hook fails, Gitaly embeds standard
output and standard error of the hook directly into a Protobuf message
along with the type of the hook that was executed and returns it to the
caller. The caller thus doesn't have to rely on parsing error message
anymore, but can instead just have a look at whether there is such an
embedded error detail and use that one instead.

Convert the operation service to handle this new error type. This once
again fixes displaying hook errors in our web interface in case merging
a merge request fails.

Changelog: fixed

Changelog: fixed

- Add tests

Changelog: changed
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/79204

Thong Kuah authored 2 years ago and Bob Van Landuyt :neckbeard: committed 2 years ago

The idea is that we want to distinguish which jobs ultimately comes from
a Cronjob

João Pereira authored 2 years ago and David Fernandez committed 2 years ago

Adds a new container_registry_migration_phase2_capacity_40
feature flag to enable a capacity of 40 concurrent migrations.

Unifies queue_duration_s calculation
and pushes it upper in middlewares stack
so it doesn't include any DB queries

- Ensure current_user is available in wiki's
  markdown rendering context

Changelog: fixed
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87611

This new table is going to be used to temporary permit a set of users to
use the certificate-based-clusters feature, which allowing us to remove
for the majority of other users. On our first attemp we tried to do this
with FF only on the namespace leve. But the spectrum of users that need
this feature enabled for longer is too big. So big that toggling the FF
for all these actors is something that our FF framework wasn't ready to
handle. So checking the enabled users directly from a table will be much
simpler, faster and easy on memory consumption.

Changelog: other

Add `gitlab:db:lock_writes` a trigger to prevent writes
due to the different gitlab_schema.
This is a mechanism that installs write trigger depending on
connections and gitlab_schemas allowed to use to prevent
changes to existing data.

Co-Authored-By: Kamil Trzciński <ayufan@ayufan.eu>

A transaction should not be open when we enqueue/finalize a batched
background migration. We have added an extra condition to
`queue_batched_background_migration` and
`finalize_batched_background_migration` that validates this assumption.
If a transaction is open, the system raises an exception.

Changelog: added

This commit adds the support for the multi-actor args
in the feature API.

Changelog: added

1. add admin setting partial to control dingtalk
2. add dingtalk_tracker_data for dingtalk_integration
3. add dingtalk_integration and dingtalk_tracker_data to pass doc_spec
and graphql check

Changelog: added

Project-level secure files are now sorted by the time they are created.

Changelog: changed
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/87546

Changelog: changed

Illya Klymov authored 2 years ago and Robert May committed 2 years ago

* respect target name and namespace provided

Changelog: fixed

Michał Zając authored 2 years ago and Matthias Käppler committed 2 years ago

Changelog: changed