| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Feature flag has been defaulting to `true` since 12.2
|
|
Kubernetes deployments on new clusters will now have
a separate namespace per project environment, instead
of sharing a single namespace for the project.
Behaviour of existing clusters is unchanged.
All new functionality is controlled by the
:kubernetes_namespace_per_environment feature flag,
which is safe to enable/disable at any time.
|
|
Using the sed script from
https://gitlab.com/gitlab-org/gitlab-ce/issues/59758
|
|
Model.new.attributes now also returns encrypted attributes.
|
|
|
|
This reverts merge request !22407
|
|
This will make it easier to perform in place adjustments, etc for future
MRs involving group clusters.
|
|
Now that Auto DevOps can run in a RBAC enabled cluster from
https://gitlab.com/gitlab-org/gitlab-ce/issues/51942, we can now remove
the FF.
As the flag only governed if UI elements would appear or not when
creating/adding existing clusters; the effect of removing the FF would
be that the checkbox to choose to enable RBAC clusters will now always
appear.
Remove FF stubs from specs
Improve spec context names
|
|
|
|
This is similar to the option in the Add Existing cluster form
|
|
feature flag is enabled
Explicitly persist the legacy_abac value of the cluster_provider_gcp so that we can disable abac if the `:rbac_clusters` feature flag is enabled
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/27070
Deprecate "chat commands" in favor of "slash commands"
We looked for things like:
- `slash commmand`
- `slash_command`
- `slash-command`
- `SlashCommand`
|
|
|
|
|
|
- While deleting a user, some of the user's associated records are moved to the
ghost user so they aren't deleted. The user is blocked before these records
are moved, to prevent the user from creating new records while the migration
is happening, and so preventing a data race.
- Previously, if the migration failed, the user would _remain_ blocked, which is
not the expected behavior. On the other hand, we can't just stick the block +
migration into a transaction, because we want the block to be committed before
the migration starts (for the data race reason mentioned above).
- One solution (implemented in this commit) is to block the user in a parent
transaction, migrate the associated records in a nested sub-transaction, and
then unblock the user in the parent transaction if the sub-transaction fails.
|
|
1. Have `MigrateToGhostUser` be a service rather than a mixed-in module, to keep
things explicit. Specs testing the behavior of this class are moved into a
separate service spec file.
2. Add a `user.reported_abuse_reports` association to make the
`migrate_abuse_reports` method more consistent with the other `migrate_`
methods.
|
|
... when the user is destroyed.
1. Normally, for a given awardable and award emoji name, a user is only allowed
to create a single award emoji.
2. This validation needs to be removed for ghost users, since:
- User A and User B have created award emoji - with the same name and against
the same awardable
- User A is deleted. Their award emoji is moved to the ghost user
- User B is deleted. Their award emoji needs to be moved to the ghost user.
However, this breaks the uniqueness validation, since the ghost user is
only allowed to have one award emoji of a given name for a given awardable
|
|
... when the user is destroyed.
|
|
1. When the user is deleted.
2. Refactor out code relating to "migrating records to the ghost user" into a
`MigrateToGhostUser` concern, which is tested using a shared example.
|
|
FFaker can generate data that randomly break our test suite. This
simplifies our factories and use sequences which are more predictive.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
https://gitlab.com/gitlab-org/gitlab-ce/issues/24007
|
|
|
|
* Webhooks for close and reopen events now fired in respective services only
* Prevents generic 'update' webhooks firing too
|
|
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
