`rules:changes` will look at last commit only

GitLab CI/CD
1

Hi,

I started using rules:changes for 2 different reasons:

  1. in workflow:rules to avoid starting the pipeline if no file was changed; this is useful with git-flow releases, that otherwise will trigger a pipeline for develop because an (empty) merge commit is pushed
  2. in single jobs to skip DB migrations in CD if no migration file was changed (DB migrations are described ad python files in django)

Now I’d like to expand the usage of the second point above to skip js tests if no js code was changed and so on…

But I noticed that rules look at the latest commit only in a multiple-commit push. This means that if I push multiple commits at once, and the last one doesn’t contain migrations, my migrations won’t run.

I understand solving this problem means to get the file diff between HEAD and the last pipeline that succeeded but I wonder how changes can be useful at all given the current implementation.

Any suggestion?

2

What version & edition of GitLab are you on?

For myself I just uploaded 2 commits, the first one has the change which triggered the rule, and the rule was triggered. Therefore GitLab Community Edition 13.5.3 seems to look farther than HEAD.

3

I just hit this with GitLab Enterprise 13.9. I pushed two commits to master. The first one contained code changes that should have triggered several pipeline steps. The second one contained only documentation changes, so only the gitlab pages job got triggered.

4

If I upload two commits, GitLab only runs one pipeline on the latest commit, for me.
That is intended functionality, to my knowledge.

Would that be what you’re seeing?

5

@n-hebert Yes, that is the intended functionality. But if I have a backend build job with rules:changes: backend/** for example, I would want that job to run in the pipeline regardless of which commit contains changes to the backend files. Right now, if the second to last commit changed backend/some-file.py, but the very last commit did not touch the backend directory at all, then the backend job will not run. If that is the intended functionality, then the rules:changes directive is all but useless.

7

I see your point, now!
That would make it quite a bit less valuable.

As mentioned in my first post, I tried this out and it worked for me.
I wonder what I did right or didn’t reproduce properly.

Maybe it would be good to show on a public GitLab project this not working as a counter example?
Does anyone have something running?

8

It works properly on merge requests, where it looks at the whole set of commits. It doesn’t work on branch pipelines.

1 Like
9

I have to say, for me it also works as intuitively expected (GitLab 13.9):
When pushing multiple commits to an existing branch, the changes are “accumulated”, e.g. the pipeline is only executed on the final commit, but runs all the jobs that had files changed by the push.

10

I guess it depends on the configuration? If you have merge pipelines not configured, only the normal “push pipelines”, only the latest commit seems to be taken into account.

Technically, GitLab itself knows what range of commits is pushed and could check all pushed commits, right?