Consider backporting documentation about Auto Build breaking change
The following discussion from !171 (merged) should be addressed:
-
@hfyngvason started a discussion: (+7 comments)
TL;DR;
We have a kind of forced breaking change impacted by an external dependency, so we have to communicate to users how to deal with it. It's only docs change (gitlab-org/gitlab!147263 (merged)), but we're considering backporting the docs as per the below context. Do you know if this is viable/acceptable?
Context
Outside of the usual range, we could try to only backport the troubleshooting changes and the
ALLOW_EOL_SHIMMED_BUILDER=1
env var usage. This might be acceptable by release managers as it's a very minor change (documentation only)
I think it's not completely necessary, but I also see value in it. Although, I'm curious:
- Whether self-managed (SM) users usually look for docs from within their SM instance.
- Whether they go to our archived docs (change the version selector from the .com docs). For instance, for 16.8: https://docs.gitlab.com/16.8/ee/topics/autodevops/customize.html
- Whether our archived docs are actually backported when we backport a documentation code.
- /cc @phillipwells for confirmation here
Edited by João Alexandre Cunha