Since it is not possible to dynamically detect if a job is automatically
cancellable or not, a this new attribute is necessary. Moreover, it let
the maintainer of the repo to adjust the behaviour of the auto cancellation
feature to match exactly what he needs.

- Added Gitlab::Ci::Config::Entry::Rules and Gitlab::Ci::Config::Entry::Rules:Rule
  to handle lists of Rule objects to be evalauted for job inclusion
- Added `if:` and `changes:` as available Rules::Rule::Clause classes
- Added Rules handling logic to Seed::Build#included? with extra specs
- Use DisallowedKeysValidator to mutually exclude rules: from only:/except: on job config

Ports changes from
https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/12343

This implements the support for `needs:` keyword
as part of GitLab CI. That makes some of the jobs
to be run out of order.

Default dependency job stage index to Infinity, and correctly report it as undefined in prior stages

Using the sed script from
https://gitlab.com/gitlab-org/gitlab-ce/issues/59758

Kamil Trzciński authored Jun 18, 2019 and Grzegorz Bizon committed Jun 18, 2019

This moves all existing `image/services/before_script/variables`
into `default:`. This allows us to easily add a default and
top-level entries. `default`: is keep backward compatible: to
be considered to be job if `default:script:` is specified. This
behavior should be removed.

All existing `image/services/before_script/variables` are properly
handled in root context.

Douwe Maan authored Apr 21, 2019 and Oswaldo Ferreir committed May 30, 2019

Gitlab::HTTP now resolves the hostname only once, verifies the IP is not
blocked, and then uses the same IP to perform the actual request, while
passing the original hostname in the `Host` header and SSL SNI field.

Require all templates to use default stages

Closes #59992

See merge request gitlab-org/gitlab-ce!26954

(cherry picked from commit 39eb16aa)

e0df05cf Require all templates to use default stages

In both e2e QA tests and unit tests, reduce the number of retires
to 2 (i.e., 1 initial and one retry)

This reverts merge request !26954

Our templates are free to override the 'stages:'.
However, they should follow the convention to always include
'build', 'test', 'deploy' which are defaults when not defined.

Paul 🐻 authored Apr 05, 2019 and Grzegorz Bizon committed Apr 05, 2019

This fix is a followup to !24098 which introduced a validation of the
`include:` keyword of a gitlab-ci configuration file when triggered
from /ci/lint API calls.

However, there was a test case missing: the case of a single string as
value. I have added a test case for that which shows that the code was
not validating it correctly.

This commit fixes that to allow all `include:` valid inputs.

In order to implement https://gitlab.com/gitlab-org/gitlab-ee/issues/10179
we need several modifications on the CI config file. We are
adding a new ports section in the default Image object.

Each of these ports will accept: number, protocol and name.

By default this new configuration will be only enabled in
the Web IDE config file.

Signed-off-by: Rémy Coutable <remy@rymai.me>

This adds `project:, file:, ref:` specification support.

These are data columns that store runtime configuration
of build needed to execute it on runner and within pipeline.

The definition of this data is that once used, and when no longer
needed (due to retry capability) they can be freely removed.

They use `jsonb` on PostgreSQL, and `text` on MySQL (due to lacking
support for json datatype on old enough version).

Drop the spec in YamlProcessor that reads current .gitlab-ci.yaml. If the .yaml file is not valid, specs would not run in CI.