3. Control when the job should run. See: [job_control](https://docs.gitlab.com/ci/jobs/job_control/), [job_rules](https://docs.gitlab.com/ci/jobs/job_rules/), and [rules](https://docs.gitlab.com/ci/yaml/#rules). By default, the job will run on any push to GitLab. Here are some common options:
3. Control when the job should run. See: [job_control](https://docs.gitlab.com/ci/jobs/job_control/), [job_rules](https://docs.gitlab.com/ci/jobs/job_rules/), and [rules](https://docs.gitlab.com/ci/yaml/#rules). By default, the job will run on any push to GitLab. Here are some common options:
**Default**
**Default**
(same as no rules)
```
```
rules:
rules:
- when: always
- when: always
```
```
**Note**: Unlike a rule of `when: always`, with no rules defined the job won't run if preceding jobs fail. Plus, with no rules defined, the job won't run for pipeline type merge request.
**On src dir file change**
**On src dir file change**
```
```
...
@@ -33,6 +34,8 @@ stages:
...
@@ -33,6 +34,8 @@ stages:
- src/**/*
- src/**/*
```
```
**Note**: For pipeline types `tag, `scheduled`, and `manual` there is no push event so changes are always `true`. See: [rules:changes](https://docs.gitlab.com/ci/yaml/#ruleschanges)
