/content as a Hugo module to track linear history #99
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This documentation contributing process is supposed to be easy and quick, to obtain an always updated doc. This is why we made a new repository on GitHub to host the whole site, and we wanted to preserve the history of the site presenting the doc to enable future maintainers to work easily on it as well.
The problem
This PR would fix the history tracking issue from old repository. Since we wanted a clonable site that contributors could test locally and deploy from GitHub to review apps on Clever Cloud, we couldn't find a solution to preserve both the building site history and the
/content
one. We wanted to avoid Git submodules, as we could see the learning curve for new contributors who never use them could be dissuasive.This solution doesn't change anything for contributors, but maintain the +10 years linear history of
/content/
.The solution
The
/content/
folder is still in this project, but has its own history thanks to a.git
history of its own. It's managed as a Hugo module, simpler to enable than Git submodules and doesn't need any cloning. The Markdown content repository is now referenced as a Hugo module, which allows the site to deploy even if its/content
folder was empty (backup, yay). It's updated by a Git hook every time a push is done at the root of this project from a doc admin's machine.Updating hook process
Every time a branch is merged into
main
, I pull changes on local and push changes to our private GitLab linked to the prod site by a pipeline. Pulling last commits will trigger a hook on my local repo (hooks aren't pushed by design and stay in the local repo).Before any push on my part, the hook will:
/content
folder/content
If approved, this
.git/hooks/pre-push
script should be added to the doc wiki for any new admin with access to the prod repo :Miscellaneous
Added details imported from old project's Readme as well.