[The `pages.expire_in` setting](https://docs.gitlab.com/ee/user/project/pages/#expiring-deployments) behaves a little inconsistent. It seems to have this behavior: ```ruby if pages.expire_in == nil # Default if parallel deployment if pages.path_prefix return '24 hours' else # Default if main deployment return 'never' end else return pages.expire_in end ``` The problem which arises from this, is that increasing the `expire_in` to e.g. `one week` _also_ sets `one week` for the `main` deployment. Unluckily one cannot use a variable to set `expire_in`. And because one can just have one `pages` job, either needs to rely on the default behavior, a high expire_in or `never`. There is seems no way to have parallel deployments expire within time frame X while setting the main deployment to `never`. See also:  which was caused by: https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/commit/99d8595121572fd440bfa43dbe9c6988b3818af6 ## Workaround: As Pages now supports [**User-defined job names**](https://docs.gitlab.com/user/project/pages/#user-defined-job-names), users can define multiple Pages jobs and set different `expire_in` values for different [rules](https://docs.gitlab.com/ci/jobs/job_rules/). #### Example: ``` main-pages: stage: deploy script: - ... pages: # specifies that this is a Pages job and publishes the default public directory expire_in: never rules: - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH mr-pages: stage: deploy script: - ... pages: # specifies that this is a Pages job and publishes the default public directory expire_in: 1 week rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" ```