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).
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:
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?
This page may contain information related to upcoming products, features and functionality.
It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.
Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Category:Fuzz Testing
GitLab Ultimate
devops
application security testing
feature flag
frontend
fuzzing
coverage
group
dynamic analysis
missed:14.7
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
missed:14.3
missed:14.4
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
Category:Fuzz Testing
Deliverable
GitLab Ultimate
backend
devops
application security testing
direction
fuzzing
coverage
group
dynamic analysis
section
sec
type
feature
workflow
in dev
@jlenny this is different. This is to run jobs only when a certain file exists. The issue/feature you linked is to run jobs only when a certain file has changed.
This is useful for Auto DevOps where the pipeline will behave a certain way if a Dockerfile exists or a different way if it does not.
We don't have a tech lead in this space at the moment. Half the time @grzesiek plays that role as a maintainer anyway so keeping him involved is more than sufficient.
What can we do to make it less confusing with only: changes? It it can confuse me, it can confuse other, who know less about these features, even more I think that using only: files to check existence of files AND directories + having only: changes is really confusing. Other ideas only: blobs:, only: exists:, only: present.
Secondly, we also now work on: https://gitlab.com/gitlab-org/gitlab-ce/issues/60085. Which seems to be duplicate of what ~Verify is doing. I don't think that we should invest anymore into adding things to only/except as this is no longer viable solution.
@ayufan this is a good point. When I came up with this plan I was assuming we will have gitlab-ce#60085 available and the only:exists will actually be a feature of this new way of excluding jobs. I recognise that only keyword is no longer appropriate but I assume that I will be able to use a similar kind of assertion where I can reject a job if none of the following files exists [Dockerfile, Gemfile, package.json...]. That is basically the intention. It's not really about whether or not we have the new only:exists syntax but really I want to have the functionality to exclude jobs if there is no file in the repo in a list of files.
@danielgruesso This may require investigation. Off the top of my head I think this will likely be very tricky for this kind of feature. Do we have usage tracking of any of the CI YML syntax features today? I'm not really aware of any.
Daniel Gruessochanged title from Extend only/except logic to look for files or directories to Extend CI only/except logic to look for files or directories
changed title from Extend only/except logic to look for files or directories to Extend CI only/except logic to look for files or directories
This feature would also be useful for gitlab-ce~4116714
See &971 (comment 200189550) for more context, but to summarize we are working to remove the requirement of Docker-in-Docker for our scanners/analyzers and being able to do something like this would be very helpful:
sast nodejs-scan:[...]only:files:-**/*.js
If I understand correctly, this issue would cover that, but please let me know if that's not the case and I will open a new issue. Thanks!
Sorry @jlenny, I think I could have been clearer. The part that we are interested in is Extend CI only/except logic to look for files or directories. We are interested in the existence of files in the context of running an individual job, not in the context of determine if a pipeline should run.
@rossfuhrman I think this issue would help with your problem as well.
We are planning on working on this soon in order to address a different issue but we actually want https://gitlab.com/gitlab-org/gitlab-ce/issues/63587 to be implemented first for Auto DevOps since we want a global rule to look for a file existing. Depending on how we implement it then it may also accomodate individual job rules as well.
@proglottis as discussed would you mind starting on this one.
Could you please update the proposal (issue description) to be inline with the new rules syntax. Also investigate if it makes sense for us to wait until global rules are implemented before this.
Will the feature allow this kind of scenario as well:
include:SAST.gitlab-ci.yml# detect langs, write some detection filessast-bandit:only:files:brakeman.txt
Where brakeman.txt would be created in sast as an artifact if the project has a Gemfile with rails.
I don't think so, as the pipeline is created and frozen during parsing, but I wanted to double-check, just in case.
@plafoucriere To me only: files: [] would be evaluated when creating the pipeline so it can't possibly depend on artifacts. This has been discussed with @tmaczukin.
Yup. .gitlab-ci.yml is parsed once, before the Pipeline is created. And only/except/rules are actionable only at this moment - this are the decision points that define if a specific job should or should not be created and with rules GitLab adds some specific configuration depending on the Rule. After the job it's created (or not), then... it is created or not :). Artifacts in the future jobs have nothing to do here.
I've updated the description to be implemented as a flexible rule instead of only/except.
Are there any thoughts on the name of this rule? I went for local in the description as this is what we use for include. Perhaps something like files or workspace is more obvious?
@ayufan any thoughts on naming? I think you've mentioned workspace before - It makes me think that the check will be on a checked out git repo which isn't really how it would work.
Do you think this will be okay for me to work on? It wont clash with any other work on flexible rules?
@proglottis Looking through the related issues and MR. From your checklist I see:
gitlab-ci.yml customisable non-matching rule messages? I think the pipeline would end up with no jobs in which case I believe it doesn't persist itself? If that's the case we'll need a better way to tell the user why their pipelines are being created.
You explicitly create a pipeline through the pipelines UI
When you have a gitlab-ci.yml where none of the jobs rules match. For example:
my_job: script: - echo My job rules: - if: "$NONEXISTANT_VAR"
For this gitlab-ci.yml there are no jobs because the var doesn't match.
In case 1 the pipeline never gets created, you get no pipeline icon on your commit.
In case 2 you get a generic error that doesn't tell you the root cause:
The form contains the following error:
No stages / jobs for this pipeline.
I think this is would be a pretty confusing situation, especially if you go check your project settings only to find auto-devops checkbox is actually checked. So I think to make this experience work, we'd likely need some way to better describe why a pipeline didn't get created because of flexible rules not matching.
create_file_job:rules:# skip job if my_file exists-exists:[my_file]when:never# otherwise run the job as long as previous stages succeeded-when:on_success