Skip to content
GitLab
Next
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    Projects Groups Topics Snippets
  • Register
  • Sign in
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
    • Locked files
  • Issues 55k
    • Issues 55k
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1.6k
    • Merge requests 1.6k
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Artifacts
    • Schedules
    • Test cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
    • Model experiments
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #24021
Closed
Open
Issue created Sep 06, 2018 by Dylan Griffith@DylanGriffith🔴Maintainer

Add file matching rule to flexible CI rules

Problem to solve

Currently it's not possible to evaluate a project's contents and use only or except logic before running a pipeline. This means that Auto DevOps pipelines run even when they won't add any value (for example on projects using a language with no matching buildpack or projects that host no code).

Intended users

developers

Further details

Proposal

Please rely on the documentation to view the accepted solution

In order to use the same mechanism Auto DevOps uses to detect a project's language (herokuish+buildpacks) and evaluate contents of a project before running a pipeline, a new flexible rule to GitLab CI so that it may look for files or directories in the relevant project. This rule will be similar to changes. This will allow us to Not run Auto DevOps when no dockerfile or matching buildpack exists

I would like to be able to do something like the following for auto devops:

build_dockerfile:
  script:
  - docker build
  rules:
    - local:
      - Dockerfile

build_herokuish:
  script:
  - docker run herokuish
  rules:
  - local:
    - Dockerfile
    when: never
  - if: '$KUBECONFIG'

Or in general we could do other things like:

rake:
  image: ruby
  script:
  - bundle install
  - bundle exec rake
  rules:
  - local:
    - Rakefile

which could replace the herokuish logic for build/test and in theory will be much more performant because it is able to cache the build images. Furthermore it allows us to customise the steps for each language a lot more easily.

Documentation

Testing

What does success look like, and how can we measure that?

TBD

Links / references

https://gitlab.com/gitlab-org/gitlab-ce/issues/57483

Edited May 12, 2020 by Tim Poffenbarger
Assignee
Assign to
Time tracking