1. 28 Oct, 2019 1 commit
  2. 21 Oct, 2019 1 commit
    • Fabio Pitino's avatar
      Expose arbitrary artifacts via MR widget · 5c168885
      Fabio Pitino authored
      * Allow user to specify `artifacts:expose_as` in CI config
      * Save :has_exposed_artifacts in job metadata for queries
      * Find exposed artifacts in build metadata model
      * Expose API endpoint for frontend to fetch data
      
      Fix unlrelated controller specs
      
      Use default has_exposed_artifacts NULL
      
      Avoid using a background migration to change NULL
      to false. It's not needed.
      
      Feedback from review
      
      * add links to issue for follow up refactoring
      * preload job artifacts and metadata associations
      * merge DisallowedRegexInArrayValidator into existing
      ArrayOfStringsValidator
      * other minor changes
      
      Rename params to match frontend code
      
      Feedback from review
      
      Feedback from review
      5c168885
  3. 17 Oct, 2019 1 commit
  4. 17 Sep, 2019 1 commit
  5. 16 Sep, 2019 1 commit
  6. 09 Sep, 2019 1 commit
  7. 05 Sep, 2019 1 commit
    • Cédric Tabin's avatar
      New interruptible attribute supported in YAML parsing. · e195e486
      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.
      e195e486
  8. 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
  9. 04 Aug, 2019 2 commits
  10. 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
  11. 31 Jul, 2019 1 commit
  12. 26 Jul, 2019 1 commit
  13. 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
  14. 05 Jun, 2019 1 commit
  15. 30 May, 2019 2 commits
  16. 15 Apr, 2019 4 commits
  17. 09 Apr, 2019 1 commit
  18. 05 Apr, 2019 5 commits
  19. 03 Apr, 2019 2 commits
  20. 19 Feb, 2019 2 commits
  21. 25 Jan, 2019 1 commit
  22. 24 Jan, 2019 2 commits
  23. 14 Jan, 2019 1 commit
  24. 07 Jan, 2019 1 commit
  25. 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