gitlab-org--gitlab-foss

Commit Graph

Author	SHA1	Message	Date
Jan Provaznik	0fc9f9d3e7	Add version 4.2 to all existing migrations DB schema generated by a migration may look different in rails 4 and 5 (because rails 5 may use different default values). For this reason it's important to explicitly set for which rails version a migration was written for. See https://stackoverflow.com/questions/35929869/activerecordmigration-deprecation-warning-asks-for-rails-version-but-im-no/35930912#35930912	2018-11-22 13:18:28 +01:00
Sean McGivern	264be20d94	Ignore existing Migration/Datetime cop offenders	2017-10-10 12:21:44 +01:00
Kamil Trzcinski	39203f1adf	Pre-create all builds for Pipeline when a trigger is received This change simplifies a Pipeline processing by introducing a special new status: created. This status is used for all builds that are created for a pipeline. We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped). This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled. This also allows us to visualise a full pipeline (with created builds). This also removes an after_touch used for updating a pipeline state parameters. Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved.	2016-08-11 15:22:35 +02:00

Author

SHA1

Message

Date

Jan Provaznik

0fc9f9d3e7

Add version 4.2 to all existing migrations

DB schema generated by a migration may look different in
rails 4 and 5 (because rails 5 may use different default values).
For this reason it's important to explicitly set for which rails
version a migration was written for.

See https://stackoverflow.com/questions/35929869/activerecordmigration-deprecation-warning-asks-for-rails-version-but-im-no/35930912#35930912

2018-11-22 13:18:28 +01:00

Sean McGivern

264be20d94

Ignore existing Migration/Datetime cop offenders

2017-10-10 12:21:44 +01:00

Kamil Trzcinski

39203f1adf

Pre-create all builds for Pipeline when a trigger is received

This change simplifies a Pipeline processing by introducing a special new status: created.
This status is used for all builds that are created for a pipeline.
We are then processing next stages and queueing some of the builds (created -> pending) or skipping them (created -> skipped).
This makes it possible to simplify and solve a few ordering problems with how previously builds were scheduled.
This also allows us to visualise a full pipeline (with created builds).

This also removes an after_touch used for updating a pipeline state parameters.
Right now in various places we explicitly call a reload_status! on pipeline to force it to be updated and saved.

2016-08-11 15:22:35 +02:00

3 Commits