| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
migration
If milestone_id is NULL, we shouldn't need to update it to be NULL again. This
was causing us to touch almost all rows in the issues table for no good
reason.
Closes https://gitlab.com/gitlab-com/infrastructure/issues/3416
|
|
I've followed the [upgrade guide](https://github.com/thoughtbot/factory_bot/blob/4-9-0-stable/UPGRADE_FROM_FACTORY_GIRL.md) and ran these two commands:
```
grep -e FactoryGirl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|FactoryGirl|FactoryBot|"
grep -e factory_girl **/*.rake **/*.rb -s -l | xargs sed -i "" "s|factory_girl|factory_bot|"
```
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
new_project_guidelines_html would be missing
Solves https://gitlab.com/gitlab-org/gitlab-ce/issues/41041.
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Fix migration that removes issues.branch_name
See merge request gitlab-org/gitlab-ce!15858
|
|
Add cop for use of remove_column
See merge request gitlab-org/gitlab-ce!15855
|
|
|
|
remove_column should only be used in the up (or change) step of a migration if
it's a post-deployment migration. Otherwise there will be downtime due to the
ActiveRecord column cache, which we can avoid by using the IgnorableColumn
concern in combination with a post-deployment migration.
|
|
This migration also needs to be a post-deployment migration, as it removes a
column.
|
|
Using update_column_in_batches means that we can chunk the updates.
|
|
|
|
|
|
|
|
Moving the check out of the general requests, makes sure we don't have
any slowdown in the regular requests.
To keep the process performing this checks small, the check is still
performed inside a unicorn. But that is called from a process running
on the same server.
Because the checks are now done outside normal request, we can have a
simpler failure strategy:
The check is now performed in the background every
`circuitbreaker_check_interval`. Failures are logged in redis. The
failures are reset when the check succeeds. Per check we will try
`circuitbreaker_access_retries` times within
`circuitbreaker_storage_timeout` seconds.
When the number of failures exceeds
`circuitbreaker_failure_count_threshold`, we will block access to the
storage.
After `failure_reset_time` of no checks, we will clear the stored
failures. This could happen when the process that performs the checks
is not running.
|
|
|
|
Add old files to uploads table
See merge request gitlab-org/gitlab-ce!15270
|
|
Add custom brand text on new project pages
Closes #15265
See merge request gitlab-org/gitlab-ce!15541
|
|
Multiple artifacts
See merge request gitlab-org/gitlab-ce!14367
|
|
|
|
|
|
|
|
|
|
|
|
This backport a change made in the CE upstream MR, see
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/3593
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
|
|
|
|
|
|
|
|
|
|
Two things at ones, as there was no clean way to seperate the commit and
give me feedback from the tests.
But the model Artifact is now JobArtifact, and the table does not have a
type anymore, but the metadata is now its own model:
Ci::JobArtifactMetadata.
|
|
To allow jobs/builds to have multiple artifacts, and to start seperating
concerns from Ci::Build a new model is created: Ci::Artifact.
Changes include the updating of the ArtifactUploader to adapt to a
slightly different interface. The uploader expects to be initialized
with a `Ci::Build`.
Futher a migration with the minimal fields, the needed foreign keys and
an index.
Last, the way this works is by prepending a module to Ci::Build so we
can basically override behaviour but if needed use `super` to get the
original behaviour.
|
|
|
|
|
|
* Hopefully fixes spec failures in which the table doesn’t exist
* Decouples the background migration from the post-deploy migration, e.g. we could easily run it again even though the table is dropped when finished.
|
|
|
|
This will prevent our other migration for adding old files to the uploads table from breaking.
|
|
I believe the field only needs to fit 519 at the moment but I’m rounding up to be a little safer.
See the migration spec for more detail on the magic number 519.
|
|
Because it is a temporary table meant only to facilitate a migration of data. It is referenced only by the post-deploy migration and 2 related background migrations.
It should be dropped when the data migration is finished.
|
|
|
|
To create the table, and schedule the background migration that begins the work.
|
|
seed-fu is detected
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
|
Remove serialised diff and commit columns
Closes #39533
See merge request gitlab-org/gitlab-ce!15582
|
|
Rescheduling will make sure the fork networks with a deleted source
project are created.
|
|
|
|
For getting the SHAs from an MR to find pipelines, we get the last 100 MR diffs
for the MR, and find commits from those. This was un-indexed before, because the
index was not a composite index on merge_request_diff_id, id. Changing that
means that this scope can exclusively use indexes.
|
|
The st_commits and st_diffs columns on merge_request_diffs historically held the
YAML-serialised data for a merge request diff, in a variety of formats.
Since 9.5, these have been migrated in the background to two new tables:
merge_request_diff_commits and merge_request_diff_files. That has the advantage
that we can actually query the data (for instance, to find out how many commits
we've stored), and that it can't be in a variety of formats, but must match the
new schema.
This is the final step of that journey, where we drop those columns and remove
all references to them. This is a breaking change to the importer, because we
can no longer import diffs created in the old format, and we cannot guarantee
the export will be in the new format unless it was generated after this commit.
|
|
This ensures that merge_requests.state and merge_requests.merge_status
both have a proper default value and NOT NULL constraint on database
level. We also make sure to update any bogus rows first, without blowing
up the database.
Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/40534
|
