1. 09 Dec, 2019 1 commit
  2. 27 Nov, 2019 1 commit
  3. 14 Nov, 2019 1 commit
  4. 08 Nov, 2019 1 commit
  5. 04 Nov, 2019 1 commit
  6. 01 Nov, 2019 1 commit
  7. 28 Oct, 2019 4 commits
    • Kamil Trzciński's avatar
      Add post compose validation · c1cb7907
      Kamil Trzciński authored and Matija Čupić's avatar Matija Čupić committed
      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
      c1cb7907
    • Matija Čupić's avatar
      Validate need types in config · e37777e4
      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
      e37777e4
    • Matija Čupić's avatar
      Move Needs entry to core · b00c3f71
      Matija Čupić authored
      Moves the Needs entry to core, because it's required for use in DAG
      needs.
      b00c3f71
    • Kamil Trzciński's avatar
      Make `Job`, `Bridge` and `Default` inheritable · f220c7fc
      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`.
      f220c7fc
  8. 16 Sep, 2019 1 commit
  9. 20 Aug, 2019 2 commits
    • drew's avatar
      Introducing new Syntax for Ci::Build inclusion rules · ac77bb93
      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
      ac77bb93
    • drew's avatar
      Introducing new Syntax for Ci::Build inclusion rules · ac449a8c
      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
      ac449a8c
  10. 13 Aug, 2019 1 commit
  11. 01 Aug, 2019 1 commit
    • Kamil Trzciński's avatar
      Add support for DAG · e7ee84aa
      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.
      e7ee84aa
  12. 29 Jul, 2019 1 commit
  13. 26 Jul, 2019 1 commit
  14. 18 Jun, 2019 2 commits
    • Kamil Trzciński's avatar
      Introduce default: for gitlab-ci.yml · a014e204
      Kamil Trzciński authored and Grzegorz Bizon's avatar Grzegorz Bizon committed
      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.
      a014e204
    • Kamil Trzciński's avatar
      Introduce default: for gitlab-ci.yml · 505d71ec
      Kamil Trzciński authored and Grzegorz Bizon's avatar Grzegorz Bizon committed
      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.
      505d71ec
  15. 05 Jun, 2019 1 commit
  16. 14 Jan, 2019 1 commit
  17. 04 Jan, 2019 2 commits
    • Kamil Trzciński's avatar
      Add config_options|variables to BuildMetadata · 0103d5be
      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).
      0103d5be
    • Kamil Trzciński's avatar
      Add config_options|variables to BuildMetadata · 9e8910b7
      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).
      9e8910b7
  18. 13 Dec, 2018 1 commit
  19. 04 Dec, 2018 2 commits
    • Shinya Maeda's avatar
      Define the default value for only/except policies · 201cd890
      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.
      201cd890
    • Shinya Maeda's avatar
      Define the default value for only/except policies · ad957a3f
      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.
      ad957a3f
  20. 08 Nov, 2018 2 commits
    • Kamil Trzciński's avatar
      Limit parallel to 100 · 036c9c58
      Kamil Trzciński authored
      This prevents some of the abusive behaviors, of someone putting 100000 and creating out of memory condition easily
      036c9c58
    • Kamil Trzciński's avatar
      Limit parallel to 100 · 270a5839
      Kamil Trzciński authored
      This prevents some of the abusive behaviors, of someone putting 100000 and creating out of memory condition easily
      270a5839
  21. 07 Nov, 2018 6 commits
  22. 27 Oct, 2018 3 commits
  23. 26 Oct, 2018 1 commit
  24. 05 Oct, 2018 1 commit
  25. 04 Oct, 2018 1 commit