Change debugging site strategy a bit?
I think it's a great idea to have some debugging content for support. It doesn't always make sense to put this directly embedded in docs and keeps things tightly grouped vs spread out in various doc pages. There might be another longterm solution, though.
Disadvantages of debugging.gitlab.io
- Maintain separate site generator in addition to content
- Potentially hoard information that might be useful to a larger audience. Yes, it's most directed at support but some is more widely useful. For example, https://debugging.gitlab.io/post/git/ could be useful to anyone!
Options?
I propose we move this in some fashion to be underneath https://docs.gitlab.com. There are a few different options for this:
- Make a directory within the GitLab repo like
doc/support/
ordoc/debugging/
.- Disadvantage: Support wouldn't be the only ones with ability to change docs and could potentially give too much freedom to the wider company/community and support wouldn't 'own' it.
- Store markdown in a separate repo (could be anything/anywhere) and then the doc site sucks it in under a relative URL like https://docs.gitlab.com/support/`. The generator already supports this to pull in Runner, CE, EE, etc.
- Advantage: Support retains merge rights but contributions are still open. Better able to curate the content and layout.
I can also see a case where it's beneficial to have some processes/steps written out that we could send to customers. For example, LDAP group sync isn't doing what we think it should. OK, please run these debug steps and send us the output: (link to support content that shows how to run the console commands , enable debug logging and send us the output). This type of thing is partially embedded in docs right now but probably makes more sense in a location like we've set up here - only to be run under support supervision.
@lbot @dstanley @harishsr @cpallares Thoughts?