feat(website): project website with nightly build tracking#651
feat(website): project website with nightly build tracking#651BrawlerXull wants to merge 2 commits into
Conversation
Adds a self-contained Hugo site and the CI to publish it (Deliverable 5).
Site (website/)
- Themeless Hugo site (all layouts in-repo, no submodule/theme fetch): landing
page, downloads page, and a docs skeleton, with a small dark stylesheet.
- A `nightly-builds` shortcode renders the build log; the downloads page shows
the most recent nightly APKs, newest first, with per-build status.
- Ships a custom-domain CNAME (taskwarrior.ccextractor.org).
Build log
- scripts/update_build_log.py prepends {ts, sha, msg, status, artifact, build}
to website/data/nightly_builds.json (keeps the 90 most recent). The file ships
empty ([]) and is populated by CI.
CI
- build-nightly.yml: daily at 02:00 UTC (+ manual) — builds the signed nightly
APK, records the result via the collector, and commits the log to main.
- deploy-website.yml: on pushes touching website/** — builds with Hugo and
deploys to GitHub Pages via actions/deploy-pages.
- nightlydepolyci.yml: ignore website/** and scripts/** so a build-log commit
does not trigger a redundant APK rebuild.
Verified locally: warning-free `hugo --minify` build (Hugo 0.164.0), and the
collector + shortcode round-trip (entry renders on the downloads page; empty
state renders when the log is []).
Deviation from the proposal, documented in website/README.md: uses the modern
GitHub Actions Pages deployment instead of renaming fdroid-repo -> public-site,
so the site source stays in website/ on main with no dedicated deploy branch.
Manual infra steps (enable Pages, DNS, branch protection) are listed there.
📝 WalkthroughWalkthroughAdds a Hugo-based TaskWarrior Mobile website with documentation, downloads, nightly build history, styling, and a custom domain. Adds workflows to build and deploy the site, generate signed nightly APKs, record build results, and avoid redundant nightly CI runs. ChangesTaskWarrior Mobile website
Estimated code review effort: 4 (Complex) | ~45 minutes Sequence Diagram(s)sequenceDiagram
participant GitHubActions
participant update_build_log.py
participant nightly_builds.json
participant GitRepository
GitHubActions->>GitHubActions: Build signed nightly APK
GitHubActions->>update_build_log.py: Pass build result and artifact metadata
update_build_log.py->>nightly_builds.json: Prepend nightly entry
GitHubActions->>GitRepository: Commit and push build log
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
82b4982 to
98ee2d9
Compare
Expand the site beyond the initial skeleton: - New Features page (wired into the nav) covering the full task model, offline-first behaviour, native TaskChampion sync, and cross-platform reach. - New Docs guides that auto-list on /docs/: getting-started, sync-setup, architecture (with a data-flow diagram), and an FAQ. - Home page: three more feature cards + an "Explore all features" link. - CSS: style markdown tables, code blocks, and blockquotes on content pages.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (4)
website/content/docs/architecture.md (1)
25-31: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueSpecify a language for the fenced code block.
As per the static analysis hints, fenced code blocks should have a language specified.
💡 Proposed refactor
-``` +```text tap "complete" ─▶ Flutter ─▶ Rust FFI ─▶ local replica (instant, no network) │ (later, when online) ▼ TaskChampion sync server</details> <details> <summary>🤖 Prompt for AI Agents</summary>Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.In
@website/content/docs/architecture.mdaround lines 25 - 31, Specify the
fenced code block language as text in the architecture documentation, preserving
the existing diagram content and formatting.</details> <!-- cr-comment:v1:3a04b7fdfc8be7c509bf4ef0 --> _Source: Linters/SAST tools_ </blockquote></details> <details> <summary>website/README.md (1)</summary><blockquote> `22-22`: _📐 Maintainability & Code Quality_ | _🔵 Trivial_ | _💤 Low value_ **Add a language identifier to the fenced code block.** Specifying a language identifier (like `text` for a directory tree) improves syntax highlighting and satisfies Markdown linting rules. <details> <summary>♻️ Proposed fix</summary> ```diff -``` +```text🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@website/README.md` at line 22, Update the fenced code block in the README content to include the text language identifier, changing the opening fence to a text-marked fence while preserving the directory tree contents and closing fence.Source: Linters/SAST tools
.github/workflows/deploy-website.yml (2)
32-35: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winPrevent credential persistence in the checked-out repository.
By default,
actions/checkoutpersists the GitHub token in the local Git configuration. This is generally unnecessary for a build job and can pose a security risk if those credentials are inadvertently captured by tools, scripts, or uploaded artifacts.Set
persist-credentials: falseto avoid storing the token.🔒️ Proposed fix
- name: Checkout uses: actions/checkout@v4 with: fetch-depth: 0 # hugo.toml enableGitInfo needs full history + persist-credentials: false🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-website.yml around lines 32 - 35, Update the actions/checkout step in the Checkout workflow action to set persist-credentials to false, while preserving the existing fetch-depth setting required for full history.Source: Linters/SAST tools
16-28: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winRestrict broad workflow permissions to the specific jobs that need them.
Defining elevated permissions (like
pages: writeandid-token: write) at the workflow level grants them to all jobs, including thebuildjob which only needscontents: read. It's a security best practice to scope permissions only to the jobs that require them.Consider moving these permissions to the
deployjob, and giving thebuildjob only the permissions it needs.🔒️ Proposed fix
-permissions: - contents: read - pages: write - id-token: write - # Allow one concurrent deployment; don't cancel an in-progress production deploy. concurrency: group: pages cancel-in-progress: false jobs: build: + permissions: + contents: read runs-on: ubuntu-latestThen, add the required permissions to the
deployjob:deploy: needs: build runs-on: ubuntu-latest + permissions: + pages: write + id-token: write environment:🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/deploy-website.yml around lines 16 - 28, Move the workflow-level permissions from the top of the deployment workflow into the individual jobs. Configure the build job with only contents: read, and add pages: write and id-token: write to the deploy job that requires them; remove the broad workflow-level permissions while preserving the existing job behavior.Source: Linters/SAST tools
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/build-nightly.yml:
- Around line 79-84: Update the nightly workflow’s repository authentication so
the commit and push of website/data/nightly_builds.json can trigger
deploy-website.yml. Configure the existing actions/checkout step to use the
repository’s PAT secret instead of the default GITHUB_TOKEN, preserving the
current commit and push flow.
- Around line 66-68: Update the scheduled nightly workflow so the built APK is
deployed to the fdroid-repo branch before the success call to
scripts/update_build_log.py. Reuse the existing deployment steps and
configuration from nightlydepolyci.yml, or unify the workflows, ensuring the
recorded nightly APK URL points to an actually pushed artifact.
---
Nitpick comments:
In @.github/workflows/deploy-website.yml:
- Around line 32-35: Update the actions/checkout step in the Checkout workflow
action to set persist-credentials to false, while preserving the existing
fetch-depth setting required for full history.
- Around line 16-28: Move the workflow-level permissions from the top of the
deployment workflow into the individual jobs. Configure the build job with only
contents: read, and add pages: write and id-token: write to the deploy job that
requires them; remove the broad workflow-level permissions while preserving the
existing job behavior.
In `@website/content/docs/architecture.md`:
- Around line 25-31: Specify the fenced code block language as text in the
architecture documentation, preserving the existing diagram content and
formatting.
In `@website/README.md`:
- Line 22: Update the fenced code block in the README content to include the
text language identifier, changing the opening fence to a text-marked fence
while preserving the directory tree contents and closing fence.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: aeff3a9e-83d4-4b23-816a-7c38587f3313
📒 Files selected for processing (23)
.github/workflows/build-nightly.yml.github/workflows/deploy-website.yml.github/workflows/nightlydepolyci.ymlscripts/update_build_log.pywebsite/.gitignorewebsite/README.mdwebsite/content/_index.mdwebsite/content/docs/_index.mdwebsite/content/docs/architecture.mdwebsite/content/docs/faq.mdwebsite/content/docs/getting-started.mdwebsite/content/docs/sync-setup.mdwebsite/content/downloads.mdwebsite/content/features.mdwebsite/data/nightly_builds.jsonwebsite/hugo.tomlwebsite/layouts/_default/baseof.htmlwebsite/layouts/_default/list.htmlwebsite/layouts/_default/single.htmlwebsite/layouts/index.htmlwebsite/layouts/shortcodes/nightly-builds.htmlwebsite/static/CNAMEwebsite/static/css/style.css
| python3 scripts/update_build_log.py success \ | ||
| "https://github.com/${{ github.repository }}/raw/fdroid-repo/repo/nightly.${{ github.run_number }}.apk" \ | ||
| "${{ github.run_number }}" |
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🔴 Critical | 🏗️ Heavy lift
Scheduled nightly APKs are never pushed to fdroid-repo.
This workflow builds the APK and records its URL as being located in the fdroid-repo branch, but it never actually pushes the APK to that branch (unlike nightlydepolyci.yml). As a result, the APK is discarded when the runner terminates, and the recorded download link will return a 404.
To fix this, you must either replicate the fdroid-repo deployment steps from nightlydepolyci.yml here before recording the success, or unify the two workflows immediately so that building, F-Droid deployment, and website logging always occur together.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build-nightly.yml around lines 66 - 68, Update the
scheduled nightly workflow so the built APK is deployed to the fdroid-repo
branch before the success call to scripts/update_build_log.py. Reuse the
existing deployment steps and configuration from nightlydepolyci.yml, or unify
the workflows, ensuring the recorded nightly APK URL points to an actually
pushed artifact.
| if git diff --quiet -- website/data/nightly_builds.json; then | ||
| echo "No build-log changes to commit." | ||
| else | ||
| git add website/data/nightly_builds.json | ||
| git commit -m "chore(nightly): record build ${{ github.run_number }}" | ||
| git push |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
The website deployment workflow will not be triggered by this push.
The comment at the top of this file states: "Committing that file to main touches website/**, which triggers deploy-website.yml".
However, GitHub Actions intentionally prevents commits made with the default GITHUB_TOKEN from spawning new workflow runs. Because actions/checkout defaults to using this token, the git push on line 84 will not trigger deploy-website.yml.
To ensure the website is automatically rebuilt after the build log is updated, you can either:
- Provide a Personal Access Token (PAT) to the
actions/checkoutstep (token: ${{ secrets.PAT }}) so the push is authenticated as a user. - Trigger the deployment explicitly at the end of this job using the GitHub CLI (
gh workflow run deploy-website.yml), assuming the default token is givenactions: writescope.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/build-nightly.yml around lines 79 - 84, Update the nightly
workflow’s repository authentication so the commit and push of
website/data/nightly_builds.json can trigger deploy-website.yml. Configure the
existing actions/checkout step to use the repository’s PAT secret instead of the
default GITHUB_TOKEN, preserving the current commit and push flow.
Adds a self-contained Hugo site and the CI to publish it (Deliverable 5).
Site (website/)
nightly-buildsshortcode renders the build log; the downloads page shows the most recent nightly APKs, newest first, with per-build status.Build log
CI
Verified locally: warning-free
hugo --minifybuild (Hugo 0.164.0), and the collector + shortcode round-trip (entry renders on the downloads page; empty state renders when the log is []).Deviation from the proposal, documented in website/README.md: uses the modern GitHub Actions Pages deployment instead of renaming fdroid-repo -> public-site, so the site source stays in website/ on main with no dedicated deploy branch. Manual infra steps (enable Pages, DNS, branch protection) are listed there.
Description
Please include a summary of the change and which issue is fixed. List any dependencies that are required for this change.
Fixes #(issue_no)
Replace
issue_nowith the issue number which is fixed in this PRScreenshots
Checklist
Summary by CodeRabbit
New Features
taskwarrior.ccextractor.org.Documentation
Style