docs-hub
docs-hub copied to clipboard
Nightly versions are the same as stable ones
Run git submodule status | sort and you'll see that, for the paths that have nightly versions, the commit IDs of stable and nightly versions are the same. For example, this file in the sway docs should be different when the docs are set to nightly but it's not.
This is happening because the commit version fetched for the nightly version is the same as the latest release, so the commit IDs of the stable and nightly submodules are the same.
After a discussion with @calldelegation to understand the intricacies of the repo, the below is the solution we agreed on.
Solution
To fix this, we'll create a cron job workflow that'll do the following:
- For every submodule that has a nightly version (listed here):
- For the nightly version, get the latest
mastercommit ID and update the nightly submodule - For the stable version, get the tags of the submodule and use semver parsing to get the latest tag's commit ID, and update the stable submodule. One shouldn't rely on getting the latest release from the GitHub API because the latest release can sometimes be an older version than the actual latest one because of e.g. a bugfix in a STS/LTS version.
- For the nightly version, get the latest
- For every submodule that doesn't have a release process, get the latest
mastercommit id and update both the stable and nightly submodule with it. - The command to update the submodules is
git submodule set-branch --branch commit_id $path_to_submodule. - Automatically merge this into
masterto trigger docs deployment.
With the solution above, we'd also solve the problem of manually updating stable versions (#571).
One thing to think to keep in mind is that multiple repos can run the workflow near simulatenously and an incorrect version of the docs would be deployed. This could be solved by having the latest workflow run stop the existing run.
Another thing to keep in mind is that the update-nightly workflow's implementation should be removed so that it doesn't conflict with the cron job. The workflow itself should be kept alive to not break the workflows of repositories using it. Those repositories can be updated to remove the workflow afterwards.
Next steps
After the solution above is implemented, we can investigate removing the submodules from the docs/nightly folder that don't actually have a nightly release process. This might require changes to the frontend app logic as well. This would result in faster deployment times because there wouldn't be a need to pull and build the docs those submodules.