If the schema changes after 20171114162227 for any of these models, and specs
after this one use factories, then those factories will use the models with
outdated column information cached.
We shouldn't really use factories in migration specs, but this is a special case
because there is a lot of git-related setup code in the model that would be
painful to copy to the migration. Instead, we just manually reset the column
information for the models we could pollute.
For each MR diff an extra 'SELECT COUNT()' is executed
to get number of commits for the diff. Overall time to get counts for
all MR diffs may be quite expensive. To speed up loading of MR info,
information about number of commits is stored in a MR diff's extra column.
Closes#38068
If the payload cannot be created for some reason, we could be left with a nil
push event payload, which causes Error 500s when viewing the dashboard. Guard
against this error and log when it happens.
Avoids problems seen in #38823
Instead of using the factories. Since the factories might be using
columns that aren't available in the schema at version the particular
spec is running in.
Later migrations added fields to the EE DB which were used by factories which were used in these specs.
And in CE on MySQL, a single appearance row is enforced.
The migration and migration specs should not depend on the codebase staying the same.
* 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.
So the path on source installs cannot be too long for our column.
And fix the column length test since Route.path is limited to 255 chars, it doesn’t matter how many nested groups there are.
That way we can join forks-of-forks into the same network even if
their original source was deleted.
Consider the following:
`awesome-oss/badger` is forked to `coolstuff/badger`, which is
forked to `user-a/badger` which in turn is forked to
`user-b/badger`.
When `awesome-oss/badger` is deleted, we will now create a fork
network with `coolstuff/badger` as the root. The `user-a/badger`
and `user-b/badger` projects will be added to the network.
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.
Before the `PopulateForkNetworksRange` spec would also call the
`CreateForkNetworkMemberships` which we would count on in the spec.
With this, I'm isolating that, and counting only records created in
this particular migration instead.
In case the root project of a Fork-of-fork is deleted, the ForkNetwork
and the membership for that fork network is never created. In this
case we shouldn't try to create the membership, since the parent
membership will never be created.
This means that these fork networks will be lost.
Micaël Bergeron
Nick Thomas
Rémy Coutable
Sean McGivern
Jan Provaznik
Jarka Kadlecová
Douwe Maan
Yorick Peterse
Stan Hu
Michael Kozono
Oswaldo Ferreira
Bob Van Landuyt