| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had concerns about the cached values on Redis with the previous two
releases strategy:
First release (this commit):
- Create new encrypted fields in the database.
- Start populating new encrypted fields, read the encrypted fields or
fallback to the plaintext fields.
- Backfill the data removing the plaintext fields to the encrypted
fields.
Second release:
- Remove the virtual attribute (created in step 2).
- Drop plaintext columns from the database (empty columns after
step 3).
We end up with a better strategy only using migration scripts in one
release:
- Pre-deployment migration: Add columns required for storing encrypted
values.
- Pre-deployment migration: Store the encrypted values in the new
columns.
- Post-deployment migration: Remove the old unencrypted columns
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is the plan to encrypt the plaintext tokens:
First release (this commit):
1. Create new encrypted fields in the database.
2. Start populating new encrypted fields, read the encrypted fields or
fallback to the plaintext fields.
3. Backfill the data removing the plaintext fields to the encrypted fields.
Second release:
4. Remove the virtual attribute (created in step 2).
5. Drop plaintext columns from the database (empty columns after step 3).
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
- A regular migration caused problems such as
https://gitlab.com/charts/gitlab/issues/1565.
|
| |
|
|
|
|
| |
Notes on epics promoted from an issue used to get same discussion_id
as the notes from the issue the epic was promoted from, which would
cause problems when trying to reply to the epic discussion.
|
| | |
|
| |
|
|
| |
Add to the service and migration both.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
These migrations do the following:
- Adds a new `issue_id` column to `versions`. This fixes an n+1 problem
when loading versions for an issue in GraphQL as AR can now load from
cache
- Change the unique restraint on versions.sha to be scoped to `issue_id`
as in order to import version data, we need to allow duplicate `sha`
values for versions
- Update all versions with an `issue_id`
https://gitlab.com/gitlab-org/gitlab-ee/issues/11090
|
| |
|
|
| |
It needs to default to an empty array logically.
|
| |
|
|
|
| |
- Set access level in before_validation hook
- Add post migration for updating existing project_features
|
| |
|
|
| |
Updates changed method names and fixes spec failures
|
| |
|
|
| |
- Change it to perform_enqueued_jobs
|
| |\
| |
| |
| |
| | |
Remove old migration specs that violate FactoriesInMigrationSpecs
See merge request gitlab-org/gitlab-ce!30280
|
| | |
| |
| |
| |
| | |
This removes old migrations that violate the
FactoriesinMigrationSpecs cop
|
| |/
|
|
|
|
| |
Add released_at field to releases API
Add released_at column to releases table
Return releases to the API sorted by released_at
|
| |
|
|
| |
Since the migrations are gone, we don't need these specs either
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a user upgraded to any GitLab 11.x EE version but switched
back to CE, it's possible the state of the EE tables are not
in the right state for the EE backport migration to work properly.
In particular, there were three tables that had trouble:
* epics
* geo_event_log
* vulnerability_feedback
The EE backport migration would fail while trying to add foreign key
constraints because a key didn't exist in the table. This happens
because any EE migration that add or removed columns between v11.0.0 and
v11.11.3 are not guaranteed to be applied in an CE installation. The EE
backport schema does not individually backport these migrations.
We now check if certain columns are present to determine whether
the backport migration is in the proper state. CE users are required
to upgrade to v11.11.3 EE if they ever installed EE previously before
they can go back to v12.x CE.
Tested via:
```
git checkout -f v11.0.0-ee
bundle exec rake db:reset
git checkout .; git checkout -f v11.11.3
bundle exec rake db:migrate
git checkout .; git checkout -f v12.0.0
bundle exec rake db:migrate
<failure happens>
```
|
| |\
| |
| |
| |
| | |
Automatically update MR merge-ref along merge status
See merge request gitlab-org/gitlab-ce!29569
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This couples the code that transitions the `MergeRequest#merge_status`
and refs/merge-requests/:iid/merge ref update.
In general, instead of directly telling `MergeToRefService` to update
the merge ref, we should rely on `MergeabilityCheckService` to keep
both the merge status and merge ref synced. Now, if the merge_status is
`can_be_merged` it means the merge-ref is also updated to the latest.
We've also updated the logic to be more systematic and less user-based.
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Migrate managed clusters that aren't using managed features to unmanaged
Closes #62772
See merge request gitlab-org/gitlab-ce!29251
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
These clusters were created before we introduced the
option to manage your own cluster, and not having a
Kubernetes namespace present means that we have tried
and failed to create one - and therefore we cannot manage
your cluster for you.
The 5 minute window should prevent a race condition
where a cluster has only just been created and we
haven't had a chance to create any resources for it
yet.
|
| | |/
|/|
| |
| |
| |
| |
| |
| | |
There are clusters that have Kubernetes namespaces
stored which are missing a service account token.
These namespaces are unable to be used for deployments,
so marking the clusters as unmanaged will allow the
platform credentials to be used instead.
|
