One of my students experienced the following error when trying to build a fork of the course project.
I found a previous similar post, but that seemed to relate to a new project that hadn’t build yet. In my case, the project has build successfully in the past and even today.
I have ask my students to provide the error following the View pipeline in GitLab link, that I will append here if I get it.
In the meantime, let me know if anyone has already experienced something similar.
Here’s what has been reported.
ERROR: Job failed: execution took longer than 1h0m0s seconds
Surprisingly, (1) starting the new environment was very fast when I tested it and (2) the timeout CI/CD settings on GitLab is set to 2h. (Note however that the students might have initially forked the project before the timeout was increased to 2h.)
Hi @lgatto, thanks for reporting this - unfortunately this is a bit of an annoying “feature” of GitLab CI. These settings are not carried over to the forks. So if you have changed it in your project, the students must do the same in their projects.
I see, indeed. Thank you @rrrrrok for pointing this out.
Is it possible to set environment variables in a config file that would be forked with the project?
hi @lgatto
you can also change the timeout in the .gitlab-ci.yaml file inside the image_build section:
image_build:
timeout: 3 hours
...
this way, the following forks will include the modified timeout
There you go, thank you very much!
I’m following up as I see some inconsistencies. I updated the gitlab-ci.yml file in the project as you suggested. It says 3 hours. However, when I check through the GitLab web interface, the CI/CD Settings still display the 2h timeout.
Similarly, when I fork the project using another user account, the forked gitlab-ci.yml file says 3 hours, but the GitLab CI/CD Settings display 1h.
Does the timout in the config file take precedence?
There are timeouts at three levels: Job level (specified in gitlab-ci.yml file), Project level (via GitLab CI/CD settings) and Runner level (setup by admins/us).
When the project is forked, it will inheritate the Job level timeout since its in the cloned file, but still have the default 1h project level timeout.
The timeout in the config file takes precedence over the project configuration, but not over the runner configuration. From the GitLab CI docs:
The job-level timeout can exceed the project-level timeout but can’t exceed the Runner-specific timeout.
Hope this made it clearer!
Thank you @pameladelgado