Skip to content
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

Website integration #365

Merged
merged 36 commits into from
Mar 22, 2024
Merged

Website integration #365

merged 36 commits into from
Mar 22, 2024

Conversation

Blacksmoke16
Copy link
Member

@Blacksmoke16 Blacksmoke16 commented Mar 20, 2024

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

Blacksmoke16 and others added 30 commits September 18, 2023 23:12
Give better header name to component API doc intro pages
Import some existing pages
Include `site_url`, `repo_url`, and `source_locations` in each component
to display repo and source code location links
Update Dotenv to use `.load`
@Blacksmoke16 Blacksmoke16 added component:ecosystem Affects all components in the ecosystem kind:documentation labels Mar 20, 2024
@Blacksmoke16
Copy link
Member Author

Blacksmoke16 commented Mar 21, 2024

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 #137 (comment), 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 😅.

@Blacksmoke16 Blacksmoke16 marked this pull request as ready for review March 22, 2024 02:41
@Blacksmoke16 Blacksmoke16 merged commit fbcae08 into master Mar 22, 2024
9 checks passed
@Blacksmoke16 Blacksmoke16 deleted the website-integration branch March 22, 2024 03:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component:ecosystem Affects all components in the ecosystem kind:documentation
Development

Successfully merging this pull request may close these issues.

Doc versioning
1 participant