Blacksmoke16
commented
6 months ago Build wise I think I can get away with having merges to master trigger a build to the dev version of the site via https://github.com/cloudflare/pages-action in the existing sync workflow. Then as part of the scripts/release.sh script, I can make a request to trigger a release workflow that'll essentially be the same as the sync version, but deploy to the prod version of the site.
In this way, the dev version will always represent the latest commit for each component. But the live version will only represent the latest release for each component. I think this is reasonable, as called out in https://github.com/athena-framework/athena/issues/137#issuecomment-1685513679, only the latest version of the component is supported at the moment. So I don't think we need to get complicated in being able to view the docs for a specific version of a component.
This approach also does require the whole doc site to be re-built on every change, even if a component was unchanged, or if only one of them was released. Don't think this is a big deal tho. Build is pretty quick and cloudflare can handle the bandwidth :sweat_smile:.
Integrates the contextual documentation into the monorepo, using the monorepo as the root mkdocs project. Each component is setup as its own project via https://squidfunk.github.io/mkdocs-material/plugins/projects/. This should make it easier to maintain as everything is now in one place.
This PR also brings some changes to the website itself to make it easier to use, navigate, and find information. The one of the added benefits is viewing the API docs for a specific component will now properly show the version/link to GH in top right corner vs always being for the framework component.
TODO:
Resolves #137