-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Restructure branches into web and guides (nightly, X.Y, etc) #2878
Comments
Instead of duplicating content, can we use +1 for the idea and effort; I think it's definitely the right direction! I see this as a valid intermediate state towards Antora (which we can but don't have to use right away). also +1 for changing the default branch to "develop" (like foreman) or "nighly" (like our URLs) |
I'm OK with all other changes, but I don't see the benefit in renaming |
That's an interesting thought. Given how little they change I'd start with duplicating (given that's what we essentially already have today) and then later revisit dynamic retrieval.
It's to simplify cases like these: foreman-documentation/.github/workflows/deploy.yml Lines 91 to 97 in 72097c1
foreman-documentation/.github/workflows/deploy.yml Lines 207 to 210 in 72097c1
Essentially make the branch map 1:1 to the target. |
Works for me. |
For a long time I've been toying with the thought to restructure branches.
After #2845 and #1204 I'm more convinced it's a good idea to tackle it.
My proposal is to have one branch for the website (like
web
) and then each for the release. I'd suggestnightly
(instead ofmaster)
and all X.Y versions.The
web
branch would only have the content ofweb
while the release branches would only have the content ofguides
. There are a few other files we'd need to remap.The challenging part is shared bits. Today
guides/common/css
andguides/common/docinfo-header.html
are symlinks toweb/content/css
andweb/layouts/nav.html.erb
respectively. Now it's already implicit that we need to keep these files in sync across all branches, so would it be OK to duplicate it once more?If we go this route, we move the
$release.json
file in #2845 into the specific branch, making branching easier. We can also generate a complete website for every GH, showing a full diff.This does overlap with Antora (#873), which has a similar structure where one branch holds the main config and then the whole site is composed by taking a bunch of branches together.
Would it make sense to invest effort in this (using nanoc) or should we jump straight to Antora?
The text was updated successfully, but these errors were encountered: