Long builds mean that all pages:deploy builds fail with "pages are outdated"
Summary
In the Haskell installation (gitlab-ce#55039) there is rarely a moment where there aren't a few a master
pipelines running. This is both due to our long CI times (typically six hours, end-to-end) and the relatively high rate of merges (queued by marge-bot, soon merge trains, gitlab-ee#9186).
However, it appears that GitLab Pages' pages:deploy
job refuses to deploy (failing with "pages are outdated") unless the commit being built is currently the head of the branch. Because of the constant flow of patches into GHC, this is nearly never the case by the time the pages:deploy
job runs. Consequently deployments essentially never happen.
Steps to reproduce
- Create a project with a long build job (e.g. such that the job length is longer than the average time between merges) followed by a pages deployment job
- Start merging patches to
master
- Note how all
pages:deploy
jobs fail with "pages are outdated"
Example Project
See https://gitlab.haskell.org/ghc/ghc
What is the current bug behavior?
All pages:deploy
jobs fail with "pages are oudated" as new commits have been added to master
by the time a commit's pages job runs.
What is the expected correct behavior?
The use should be allowed to configure whether outdated pages deployments should be allowed to run. In GHC's case the deployment is just documentation. It does not matter if the deployment is slightly out of date; we just need to ensure that deployments actually happen.
Relevant logs and/or screenshots
None.
Output of checks
This bug happens on GitLab.com
Possible fixes
See expected correct behavior above.