gitlab-org--gitlab-foss/app/models/ci/pipeline_enums.rb

41 lines
833 B
Ruby
Raw Normal View History

Refactor how a few ActiveRecord enums are defined 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
2018-11-13 11:29:14 -05:00
# frozen_string_literal: true
module Ci
module PipelineEnums
# Returns the `Hash` to use for creating the `failure_reason` enum for
# `Ci::Pipeline`.
def self.failure_reasons
{
unknown_failure: 0,
config_error: 1
}
end
# Returns the `Hash` to use for creating the `sources` enum for
# `Ci::Pipeline`.
def self.sources
{
unknown: nil,
push: 1,
web: 2,
trigger: 3,
schedule: 4,
api: 5,
2018-12-05 01:57:00 -05:00
external: 6,
chat: 8,
merge_request_event: 10
Refactor how a few ActiveRecord enums are defined 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
2018-11-13 11:29:14 -05:00
}
end
# Returns the `Hash` to use for creating the `config_sources` enum for
# `Ci::Pipeline`.
def self.config_sources
{
unknown_source: nil,
repository_source: 1,
auto_devops_source: 2
}
end
Refactor how a few ActiveRecord enums are defined 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
2018-11-13 11:29:14 -05:00
end
end