Does retrying a job pull in changes to an included CI template?

GitLab CI/CD
1

I’m working on some CI templates. Those templates live in one project (on a branch that hasn’t been merged yet) and the project I’m testing them with (call it app) is separate. So app has a .gitlab-ci.yml file that looks a bit like

include:
  - project: .../gitlab-ci-templates
    file: template1.yml
  - project: .../gitlab-ci-templates
    file: template2.yml
    ref: duvall/test

job:
  - extends: .template2

and the .template2 template, living in gitlab-ci-templates (on the branch duvall/test):

.template2:
  image: ...
...

My template doesn’t work yet, so my app jobs are failing. I want to just hit the retry button after I’ve updated the template and pushed to gitlab-ci-templates, but the log of the new job suggests that the changes haven’t been picked up yet. If I make an arbitrary change to app and push it, the corresponding pipeline run definitely does pick up the change. So does the job retry use a cached copy of the included files? Is there something else I should be doing instead?

This is on gitlab.com.

Thanks!

2

Hi @dhduvall

retry button would use the same ref all the time. You need to start a new pipeline to use newer ref of included files.

1 Like
3

Thanks. I finally found the “Run pipeline” button so I don’t have to make dummy changes to the including project, but I’m a bit sad that I have to run the entire pipeline rather than just the section of it I’m working on. That said, it shouldn’t be hard to work around with temporary rules.

4

Thanks for sharing this. Personally, I find it a bit annyoing and unexpected. In Jenkins you can rerun failed pipeline following changes in shared libarary the pipeline includes. In GitLab, the solution is not trivial and causes noise to developers of the pipelines (devops), while in Jenkins the pipeline can be rerun by the developers…

In addition, in case of MR pipelines, i haven’t found a way not do a dummy change to cause the pipeline to pick the changes in the imported templates… The trick you shared works only for branch pipelines… That’s frustrating even more …

5

FWIW, it is documented, in a reasonably obvious place. Whether it was a year ago, I don’t know. I certainly could have missed it. I can understand doing it either way, but I was surprised at the time. I still think it would be nice to be able to rerun a job but have it pick up updated includes (and variables, too), but as an explicit non-default option.

I’m surprised the rerun pipeline thing doesn’t work for for MR pipelines, but maybe that’s because it has something to do with how CI_PIPELINE_SOURCE is different between the two runs, or some other variable that changes based on how the pipeline ran. I guess you could add a variable to your CI configuration which a manually triggered pipeline could check and then reset things to make it pretend it’s a job of your preferred type.

Or, as I think I was getting at before, a variable that would turn off all jobs other than the one(s) you actually want, which is pretty simple, if a bit silly for this purpose.

6

Dummy commits to start MR pipelines was the case in older versions of GitLab. Now in MR under Pipelines tab is a Run pipeline button which allows you to start MR pipeline manually.