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
Enum in Rails 5 does not map nil values - IOW nil value remains nil,
even if there is a key with nil value in the enum definition.
This commit overrides the underlying Enum methods so nil value is
still mapped. This solution is far from being ideal: it uses dynamic
definition of methods which introduces more magic/confusion
into the codebase.
It would be better to get rid of the nil value in enums.
GitLab Bot
Kamil Trzciński
Sean McGivern
Heinrich Lee Yu
Nick Thomas
Tiger
Grzegorz Bizon
Yorick Peterse
George Tsiolis
Shinya Maeda
Rémy Coutable
gfyoung
Jan Provaznik
Mayra Cabrera
blackst0ne
Tomasz Maczukin
Zeger-Jan van de Weg
Takuya Noguchi