Conversation
dc4c0cf to
21fa8ee
Compare
|
Fixes #52. |
|
Wow, is it done? I will take a look at it later. |
There was a problem hiding this comment.
Pull request overview
This PR refactors and expands the repository’s human-authored documentation and adds TypeDoc generation/publishing so ./docs/api can be published as GitHub Pages.
Changes:
- Add new
docs/guides (quickstart, CI, env vars, routes/plugins overviews, deployment, release notes, testing/linting). - Add TypeDoc configuration + scripts, and ignore generated output (
docs/api) in git. - Add GitHub Actions workflows to build docs and publish generated TypeDoc output.
Reviewed changes
Copilot reviewed 19 out of 21 changed files in this pull request and generated 10 comments.
Show a summary per file
| File | Description |
|---|---|
yarn.lock |
Adds TypeDoc and its transitive dependencies to the lockfile. |
typedoc.json |
TypeDoc configuration targeting src/ and outputting to docs/api. |
src/routes/README.md |
Removes old routes folder README in favor of centralized docs under docs/. |
src/plugins/README.md |
Removes old plugins folder README in favor of centralized docs under docs/. |
scripts/clean-docs.js |
Adds a helper script to remove generated TypeDoc output directory. |
package.json |
Adds docs:typedoc / docs:clean scripts and typedoc devDependency. |
docs/testing-and-linting.md |
New guide for running tests and linting locally. |
docs/routes.md |
New overview of route loading/structure and where generated docs live. |
docs/release.md |
New summary of release automation workflow behavior. |
docs/quickstart.md |
New expanded quickstart guide for local setup and usage. |
docs/plugins.md |
New overview of plugin loading and key plugins provided. |
docs/env-vars.md |
New environment variable guide and conventions (incl. .env* ignore). |
docs/docker-and-deployment.md |
New Docker build/run and CI publishing guide. |
docs/dev-setup.md |
New developer setup guide focusing on Corepack/Yarn. |
docs/ci.md |
New overview of CI workflows and hosted/self-hosted fallback behavior. |
README.md |
Refactors README to link to docs/scripts and describe docs generation. |
CONTRIBUTING.md |
Improves wording/formatting for contribution guidelines. |
.gitignore |
Ignores generated TypeDoc output under docs/api/. |
.github/workflows/docs.yml |
New workflow to generate TypeDoc and upload it as an artifact on PR/push. |
.github/workflows/docs-publish.yml |
New workflow intended to publish docs/api output to GitHub Pages on main. |
.env.example |
Expands env example with auth skip/runtime/test helper variables. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Details will be moved under `docs/`.
…nd runner defaults
… docker metadata, release-please behavior
…te README and .gitignore
… cache for docs workflows Use numeric node-version (24) in `.github/workflows/docs.yml` and `.github/workflows/docs-publish.yml` Enable Corepack and run `corepack install` before installing dependencies Split node/cache setup to a dedicated `setup-node` step with `cache: yarn` Reorder and consolidate dependency install steps (Corepack prepare + yarn install --frozen-lockfile) Minor comment formatting fix in `docs-publish.yml`
Grant pages write permission; use yarn install --immutable --immutable-cache instead of corepack prep.
Update README docs-site badge to GitHub Pages URL and minor docs wording fixes. Remove UTF-8 BOM from `.env.example`.
615ba34 to
9abe148
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 19 out of 21 changed files in this pull request and generated 6 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
You might also want to fix the runner selection for this repo. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 19 out of 21 changed files in this pull request and generated 4 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| ## Key notes | ||
|
|
||
| - Hosted-first fallback: jobs use a small probe job (`detect-quota`) and set `runs-on` dynamically so CI prefers `ubuntu-latest` but can fall back to `self-hosted` when needed. |
There was a problem hiding this comment.
The documentation states that CI jobs prefer ubuntu-latest, but the actual workflow files (check.yml, docs.yml, docs-publish.yml) use ubuntu-slim as the hosted runner label. Update this line to reference ubuntu-slim to match the actual implementation.
| - Hosted-first fallback: jobs use a small probe job (`detect-quota`) and set `runs-on` dynamically so CI prefers `ubuntu-latest` but can fall back to `self-hosted` when needed. | |
| - Hosted-first fallback: jobs use a small probe job (`detect-quota`) and set `runs-on` dynamically so CI prefers `ubuntu-slim` but can fall back to `self-hosted` when needed. |
| name: docs | ||
|
|
||
| on: | ||
| push: | ||
| pull_request: | ||
| workflow_dispatch: | ||
|
|
There was a problem hiding this comment.
Consider adding concurrency control to this workflow (similar to check.yml and docker.yml) to avoid redundant doc builds when multiple commits are pushed to the same PR. This would save CI resources and reduce noise. Example:
concurrency:
group: ${{ github.workflow }}-${{ github.event_name == 'pull_request' && format('pr-{0}', github.event.pull_request.number) || github.sha }}
cancel-in-progress: true| Releases are produced by `googleapis/release-please-action`. The release workflow has been refactored so release steps are defined in `.github/workflows/release-shared-steps.yml` and invoked by a small top-level caller (`.github/workflows/release.yml`) which prefers hosted runners and falls back to `self-hosted` when the top-level try job fails. | ||
|
|
||
| - Trigger: push to `main`. | ||
| - Behavior: `googleapis/release-please-action` parses Conventional Commits and will open/update Release PRs or create a release when appropriate; it also generates/updates the changelog (`CHANGELOG.md`) and exposes outputs such as `release_created`, `major`, `minor`, `patch`, `tag_name`, and `body`. | ||
| - CI integration: the shared-step workflow consumes those outputs to tag versions and to build/push container images (see the repository workflows for exact steps). The hosted-first / self-hosted fallback may cause duplicate PR checks to appear when the fallback runs — this is cosmetic. |
There was a problem hiding this comment.
The documentation describes a "shared-step workflow" (release-shared-steps.yml) and a "top-level caller", but the release workflow is actually defined entirely in .github/workflows/release.yml with no separate shared-steps file. Update this section to accurately describe the single release.yml workflow that contains all release steps inline.
| Releases are produced by `googleapis/release-please-action`. The release workflow has been refactored so release steps are defined in `.github/workflows/release-shared-steps.yml` and invoked by a small top-level caller (`.github/workflows/release.yml`) which prefers hosted runners and falls back to `self-hosted` when the top-level try job fails. | |
| - Trigger: push to `main`. | |
| - Behavior: `googleapis/release-please-action` parses Conventional Commits and will open/update Release PRs or create a release when appropriate; it also generates/updates the changelog (`CHANGELOG.md`) and exposes outputs such as `release_created`, `major`, `minor`, `patch`, `tag_name`, and `body`. | |
| - CI integration: the shared-step workflow consumes those outputs to tag versions and to build/push container images (see the repository workflows for exact steps). The hosted-first / self-hosted fallback may cause duplicate PR checks to appear when the fallback runs — this is cosmetic. | |
| Releases are produced by `googleapis/release-please-action`, via a single workflow defined in `.github/workflows/release.yml`. This workflow prefers hosted runners and falls back to `self-hosted` when the top-level try job fails. | |
| - Trigger: push to `main`. | |
| - Behavior: `googleapis/release-please-action` parses Conventional Commits and will open/update Release PRs or create a release when appropriate; it also generates/updates the changelog (`CHANGELOG.md`) and exposes outputs such as `release_created`, `major`, `minor`, `patch`, `tag_name`, and `body`. | |
| - CI integration: the `release.yml` workflow consumes those outputs to tag versions and to build/push container images (see the repository workflows for exact steps). The hosted-first / self-hosted fallback may cause duplicate PR checks to appear when the fallback runs — this is cosmetic. |
| A `Dockerfile` exists at the repository root. CI image build/publish logic has been extracted into an internal shared-step workflow (`.github/workflows/docker-shared-steps.yml`) and is invoked by a small top-level caller (`.github/workflows/docker.yml`) that prefers hosted runners and falls back to `self-hosted` when the hosted job fails. | ||
|
|
||
| ## Local build & run | ||
|
|
||
| Build the image locally (from repo root): | ||
|
|
||
| ```bash | ||
| # build | ||
| docker build -t template-api:local . | ||
|
|
||
| # run (expose port 3000) | ||
| docker run --rm -p 3000:3000 --env-file .env.example template-api:local | ||
| ``` | ||
|
|
||
| Replace `--env-file .env.example` with your `.env` file or explicit `-e` flags for required environment variables. | ||
|
|
||
| ## CI image publishing | ||
|
|
||
| The repository's `docker.yml` top-level caller invokes the internal shared-step workflow to build and push images to the registry. The shared-step workflow: | ||
|
|
||
| - sets up QEMU and Buildx | ||
| - logs into the registry using the workflow token | ||
| - generates metadata tags (sha, branch/ref, test) | ||
| - builds and pushes the image(s) | ||
|
|
||
| If you need to change the target registry or image name, update the `REGISTRY` and `IMAGE_NAME` environment variables in the shared-step workflow or the top-level caller as appropriate. |
There was a problem hiding this comment.
The documentation describes a "shared-step workflow" (docker-shared-steps.yml) and a "top-level caller", but the docker workflow is actually defined entirely in .github/workflows/docker.yml with no separate shared-steps file. Update this section to accurately describe the single docker.yml workflow that contains all build/push steps inline.
Apart from adding docs, this adds a workflow to publish "./docs/api" as GH pages. Might need to set it up.
Fixes #52.