| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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
|
|
Add released_at field to releases API
Add released_at column to releases table
Return releases to the API sorted by released_at
|
|
This removes old migrations that violate the
FactoriesinMigrationSpecs cop
|
|
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
|
|
Migrate managed clusters that aren't using managed features to unmanaged
Closes #62772
See merge request gitlab-org/gitlab-ce!29251
|
|
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.
|
|
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.
|
|
Add migrations needed to encrypt feature flags client tokens
See merge request gitlab-org/gitlab-ce!29320
|
|
Migrate Kubernetes service integration templates to clusters
See merge request gitlab-org/gitlab-ce!28534
|
|
Make plaintext token column not null, add new token_encrypted column and
index on project_id & token_encrypted.
Post deployment migration to encrypt existing tokens.
|
|
This backports all EE schema changes to CE, including EE migrations,
ensuring both use the same schema.
== Updated tests
A spec related to ghost and support bot users had to be modified to make
it pass. The spec in question assumes that the "support_bot" column
exists when defining the spec. In the single codebase setup this is not
the case, as the column is backported in a later migration. Any attempt
to use a different schema version or use of "around" blocks to
conditionally disable specs won't help, as reverting the backport
migration would also drop the "support_bot" column. Removing the
"support_bot" tests entirely appears to be the only solution.
We also need to update some foreign key tests now that we have
backported the EE columns. Fortunately, these changes are very minor.
== Backporting migrations
This commit moves EE specific migrations (except those for the Geo
tracking database) and related files to CE, and also removes any traces
of the ee/db directory.
Some migrations had to be modified or removed, as they no longer work
with the schema being backported. These migrations were all quite old,
so we opted for removing them where modifying them would take too much
time and effort.
Some old migrations were modified in EE, while also existing in CE. In
these cases we took the EE code, and in one case removed them entirely.
It's not worth spending time trying to merge these changes somehow as we
plan to remove old migrations around the release of 12.0, see
https://gitlab.com/gitlab-org/gitlab-ce/issues/59177 for more details.
|
|
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.
|
|
Due to a bug, some pool_repositories in production have a null
source_project_id column. This migration aims to fix those rows.
|
|
|
|
Add project level git depth setting
Closes #59688
See merge request gitlab-org/gitlab-ce!28919
|
|
Save certificate validity time for pages domains on save
Fill validity time for existing pages domains in background migration
|
|
This reverts merge request !28743
|
|
Save certificate validity time for pages domains on save
Fill validity time for existing pages domains in background migration
|
|
We need to stub default_git_depth and default_git_depth= because some
old migrations specs try to create a record using schema before that
column was introduced.
|
|
Introduce default_git_depth in project's CI/CD settings and set it to
50. Use it if there is no GIT_DEPTH variable specified. Apply this
default only to newly created projects and keep it nil for old ones
in order to not break pipelines that rely on non-shallow clones.
default_git_depth can be updated from CI/CD Settings in the UI, must be
either nil or integer between 0 and 1000 (incl).
Inherit default_git_depth from the origin project when forking projects.
MR pipelines are run on a MR ref (refs/merge-requests/:iid/merge) and it
contains unique commit (i.e. merge commit) which doesn't exist in the
other branch/tags refs. We need to add it cause otherwise it may break
pipelines for old projects that have already enabled Pipelines for merge
results and have git depth 0.
Document new default_git_depth project CI/CD setting
|
|
When a Group is missing a route, the migration failed previously with a
`Invalid single-table inheritance type` error. To fix this, we can
disable STI for the migration class because we don't need to know about
the type to do this migration. Besides, currently Group is the only type
used in the type column.
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/58714
|
|
Reset merge status from mergeable MRs
See merge request gitlab-org/gitlab-ce!28843
|
|
Adds migrations to reset the merge_status of opened,
mergeable MRs. That's required by
https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/28513
so we're able to sync the status update along merge-ref,
without leaving MRs with a stale merge-ref.
|
|
Remove legacy artifact related code
Closes #58595
See merge request gitlab-org/gitlab-ce!26475
|
|
Now it defaults to 0
|
|
Remove migration generating lets encrypt key
Don't generate private_key if database is readonly
For reference:
This reverts commit 988a7f70489b99383b95e9f271a2caf6bb5b3a44.
This reverts commit 21acbe531592d55caf0e5b8716a3b551dafd6233.
|
|
We've already migrated all the legacy artifacts to the new realm,
which is ci_job_artifacts table.
It's time to remove the old code base that is no longer used.
|
|
Assume that if an instance level cluster already exists, then the
KubernetesService was not being used, but allow the admin to re-enable
it if required
|
|
The migration uses active record model stubs so that field encryption
can be more easily used.
|
|
Storing this key in secrets.yml was a bad idea,
it would require users using HA setups to manually
replicate secrets across nodes during update,
it also needed support from omnibus package
* Revert "Generate Let's Encrypt private key"
This reverts commit 444959bfa0b79e827a2a1a7a314acac19390f976.
* Add Let's Encrypt private key to settings
as encrypted attribute
* Generate Let's Encrypt private key
in database migration
|
|
Issues and merge requests imported from GitHub are having state_id
set to null. This fixes the GitHub project importer and schedule
migrations to fix state_id.
|
|
This was incorrectly set by a bug in:
https://gitlab.com/gitlab-org/gitlab-ce/issues/54924
Also adds a `batch_size` option to `update_column_in_batches`
|
|
Add a length limit of 128 char to the user name field
See merge request gitlab-org/gitlab-ce!26146
|
|
- rewords examples starting with 'should'
- rewords examples starting with 'it'
Note: I had to manually fixup "onlies" to "only"
|
|
Truncate existing users names which exceed 128 characters
Include test for truncating users names
|
|
spec/migrations/schedule_sync_issuables_state_id_spec.rb
|
|
Migrate issuable states to integer patch 1 of 2
Closes #51789
See merge request gitlab-org/gitlab-ce!25107
|
|
- Creates a support/helper file and moves all the duplication defs
into it
|
|
|
|
|
|
This will be further required for supporting multi-assignees MRs
|
