- 09 Dec, 2019 2 commits
-
-
Cédric Tabin authored
-
Allows for including or excluding bridge jobs via `rules:` to control triggering of downstream (multi-project) Pipelines.
-
- 27 Nov, 2019 1 commit
-
-
Will Layton authored
-
- 24 Nov, 2019 1 commit
-
-
Cédric Tabin authored
-
- 14 Nov, 2019 2 commits
-
-
drew authored
Separated class-level validation from a class constant, which lists all allowable values, from instance-level validation via factory metadata providing the allowed values (subset of class constant) for that specific instance. Added validation specs for both created and composed entries.
-
Cédric Tabin authored
-
- 08 Nov, 2019 1 commit
-
-
Cédric Tabin authored
-
- 04 Nov, 2019 1 commit
-
-
Sean McGivern authored
Separate bridge and DAG needs Closes #14928 and #30675 See merge request gitlab-org/gitlab!17539
-
- 01 Nov, 2019 1 commit
-
-
Marin Jankovski authored
This reverts merge request !17539
-
- 29 Oct, 2019 1 commit
-
-
Kamil Trzciński authored
-
- 28 Oct, 2019 4 commits
-
-
Use post compose validation: - ensure that bridge has a valid number of entries - use simplifiable to construct need type - use aspect with opt to indicate allowed opts
-
Matija Čupić authored
Validates need types in Job and Bridge config. - Only Pipeline type needs are allowed in regular jobs - Only Bridge and Pipeline type needs are allowed in bridge jobs - Only one Bridge type need is allowed in a bridge job
-
Matija Čupić authored
Moves the Needs entry to core, because it's required for use in DAG needs.
-
Kamil Trzciński authored
This changes `Job`, `Bridge` and `Default` to use `Inheritable` to inherit the configuration. Shared example ensure that all fields are annotated with `inherit:` and does have matching type when inherited. Since the `Default:` is shared, it requires that inheritable fields to be also added to `Job` and `Bridge`.
-
- 17 Sep, 2019 1 commit
-
-
This changes any mention of gitlab-ce to gitlab-foss, and any mention of gitlab-ee to just gitlab.
-
- 16 Sep, 2019 1 commit
-
-
Fabio Pitino authored
When timeout is not specified the project.build_timeout is used. The timeout is specified in seconds.
-
- 09 Sep, 2019 1 commit
-
-
drew authored
-
- 05 Sep, 2019 1 commit
-
-
Cédric Tabin authored
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.
-
- 20 Aug, 2019 2 commits
-
-
drew authored
- 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
-
drew authored
- 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
-
- 13 Aug, 2019 1 commit
-
-
Kamil Trzciński authored
Since we are unsure what would be the behavior of `stage:` when we work on DAG. Let's make `stage:` to be required today with `needs:`.
-
- 01 Aug, 2019 1 commit
-
-
Kamil Trzciński authored
This implements the support for `needs:` keyword as part of GitLab CI. That makes some of the jobs to be run out of order.
-
- 18 Jun, 2019 2 commits
-
-
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.
-
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.
-
- 05 Jun, 2019 1 commit
-
-
Wolphin authored
-
- 25 Jan, 2019 1 commit
-
-
Grzegorz Bizon authored
We reuse this constant in EE.
-
- 15 Jan, 2019 2 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
Introduce `default:` configuration entry setting that makes it possible to configure a default value of an entry, what overrides class-level `def self.default` value.
-
- 14 Jan, 2019 2 commits
-
-
Grzegorz Bizon authored
-
Grzegorz Bizon authored
This commit refactors only/except policies so that these policies could be self-contained. This also adds some changes to YAML configuration library to provide more context to default entry value fabrication process.
-
- 04 Jan, 2019 2 commits
-
-
Kamil Trzciński authored
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).
-
Kamil Trzciński authored
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).
-
- 13 Dec, 2018 1 commit
-
-
- 04 Dec, 2018 2 commits
-
-
Shinya Maeda authored
Currently, if a job does not have only/except policies, the policy is considered as an unspecified state, and therefore the job is executed regardless of how it's executed and which branch/tags are targetted. Ideally, this should be specified as only: ['branches', 'tags'], as it indicates that unspecified policy jobs are meant to run on any git references.
-
Shinya Maeda authored
Currently, if a job does not have only/except policies, the policy is considered as an unspecified state, and therefore the job is executed regardless of how it's executed and which branch/tags are targetted. Ideally, this should be specified as only: ['branches', 'tags'], as it indicates that unspecified policy jobs are meant to run on any git references.
-
- 29 Nov, 2018 1 commit
-
-
Kamil Trzciński authored
This decouples Ci::Config to provide a common interface for handling user configuration files.
-
- 08 Nov, 2018 3 commits
-
-
Kamil Trzciński authored
This prevents some of the abusive behaviors, of someone putting 100000 and creating out of memory condition easily
-
Kamil Trzciński authored
This prevents some of the abusive behaviors, of someone putting 100000 and creating out of memory condition easily
-
Steve Azzopardi authored
Fix conflict for ce-to-ee-2018-11-07
-
- 07 Nov, 2018 1 commit
-
-
Markus Doits authored
-