This changes used worker from `BuildProcessWorker`
to `PipelineProcessWorker` to make pipeline
processing much simpler. We process `pipeline_id`,
based on some triggers.
Currently, some of the jobs with `needs:`
would be processed in stages, it means
that `when:` for such jobs would not be
respected.
This changes the behavior to have a separate
execution paths for jobs with `needs:`.
Introduces the concept of Prerequisites for a CI build.
If a build has unmet prerequisites it will go through the
:preparing state before being made available to a runner.
There are no actual prerequisites yet, so current
behaviour is unchanged.
Introduces a new status for builds between :created and :pending
that will be used when builds require one or more prerequisite
actions to be completed before being picked up by a runner
(such as creating Kubernetes resources before deploying).
The existing :created > :pending transition is unchanged, so
only builds that require preparation will use the :preparing
status.
In a few models we define ActiveRecord enums that are redefined in EE
using the following pattern:
enum :some_enum, {
...
}.merge(EE_ENUM_VALUES)
This particular approach is problematic to deal with, because it
requires that we `prepend` and EE module _before_ defining the enum.
This typically translates to the `prepend` being the first line in the
model in EE, but this can easily lead to merge conflicts when developers
add more `include` and/or `prepend` lines.
As part of https://gitlab.com/gitlab-org/gitlab-ee/issues/8244 and
https://gitlab.com/gitlab-org/gitlab-ee/issues/8241 we are moving
`prepend` to the last line in a file, reducing the chances of running
into merge conflicts. This poses a bit of a problem with the pattern
above, because this pattern does not allow us to move the `prepend`
further down a file.
To resolve this problem, we simply move the Hash value of the enum to a
separate class method. This method is defined in a separate module where
necessary, allowing us to use it like so:
enum :failure_reasons, ::SomeModelEnums.failure_reasons
The method in turn is defined in a very straightforward manner:
module SomeModelEnums
def self.failure_reasons
{
...
}
end
end
This makes it easy for EE to add values without requiring the `prepend`
to be placed before the `enum` is defined.
For more information, see the following issues and merge requests:
* https://gitlab.com/gitlab-org/gitlab-ee/issues/8244
* https://gitlab.com/gitlab-org/gitlab-ee/issues/8241
* https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/8424
GitLab Bot
Robert Speicher
Kamil Trzciński
Sean McGivern
Heinrich Lee Yu
Nick Thomas
Tiger
Grzegorz Bizon
Yorick Peterse