Formatting of final rendered doc pages is different from issue fork file

I fixed the numbered list issue with this commit https://git.drupalcode.org/project/gitlab_templates/-/commit/24c521651c7...

We have this way https://project.pages.drupalcode.org/gitlab_templates/help/documentation..., which matches 1 to 1 with the online version, but I understand that it needs local tooling which might not be easy to get. I normally scan the code only, and only do it this way if there are many changes or new pages, so it's my bad for not having tested it.

I'm not sure how we can make it easier but happy to investigate.

Thanks for fixing. Adding a blank line was going to be my first suggestion, but as I don't have the local tools I could not check it. I guess viewing the file in the issue fork is not to be relied on totally.

Would it be possible to use CI variables in the gitlab templates project to re-build all the docs only in specific merge requets, for example on the latest doc MR, part of the change would be to include that MR number in an extra condition in this rule. Then the docs could be built in full for checking. It would be only in the issue branch, not the "real" published site.

I guess viewing the file in the issue fork is not to be relied on totally.

Note to myself: do check locally all the new pages locally, don't rely only on checking the code via the MR screen.

Would it be possible to use CI variables in the gitlab templates project to re-build all the docs only in specific merge requets

I tried this in #3426311: Allow testing documentation pages via MRs → and it's not possible in our instance.

I guess viewing the file in the issue fork is not to be relied on totally.

This was also a note to myself.

I like editting the doc files here in the UI, not locally, as it gives an immediate preview with split screen. But I could try getting the local tools again.

Thanks for linking that other issue. Shame it did not work out. If there is nothing else to do on this issue you can close it.

Yeah, I'll close it unless you want to maybe investigate on the tooling available.

The tooling that we have right now allows for "easy" local testing once you've got docker installed. Do you have any other container-like tool that we can investigate? I got some of the alternatives from here https://squidfunk.github.io/mkdocs-material/getting-started/, maybe there is something that works for you.

Feel free to reopen/repurpose the issue if you want to use it as investigation on alternatives (and then update the docs accordingly).