* [AI] Relax release-notes filename convention
Allow descriptive filenames (e.g. add-payee-autocomplete.md) for
upcoming release notes instead of requiring {PR_NUMBER}.md.
The PR number was only used to build the [#1234](.../pull/1234) link in
the generated changelog. The generation script now resolves the PR per
file by finding the commit that added it (git log --diff-filter=A
--follow) and querying GitHub's commits/{sha}/pulls endpoint. Numeric
filenames remain valid via a fast path.
Also retires the CodeRabbit/OpenAI-triggered auto-creator workflow,
which existed to guess summaries and stamp the PR-numbered filename;
neither is needed once contributors can pick a slug up front.
* Add release notes for PR #7963
* [AI] Use execFile to look up release-note add-commits
resolvePrNumber() interpolated a path from fs.readdir into a shell-
evaluated `git log` command. Switch to execFile with an argv array so
filenames containing shell metacharacters can't break out of the
intended command.
* [AI] Drop duplicate release note added by the to-be-removed auto-creator
The CodeRabbit-triggered workflow ran one last time from master before
this PR removes it, and committed upcoming-release-notes/7963.md
duplicating the existing relax-release-notes-filenames.md entry. Keep
the slug-named note since it exercises the new flexible-filename code
introduced in this PR.
* [AI] Don't fail release-notes generation on transient API errors
fetchPrForCommit() handled non-OK HTTP responses but let fetch() and
res.json() exceptions propagate, so a single network blip or malformed
response would abort the whole release-notes generation. Wrap them in a
try/catch that logs and returns null, matching the pattern already used
in resolvePrNumber for execFile errors.
* [AI] Address CodeRabbit full-review nits
- bin/release-note-generator.ts: tighten slug regex to reject trailing
and consecutive dashes (matching slugify output), and make slugify
fall back to "untitled" so an all-non-alphanumeric input can't
produce a hidden ".md" filename.
- packages/ci-actions/bin/release-notes-check.mjs: switch to execFile
for git fetch/diff, matching release-notes-generate.mjs and removing
shell interpolation of BASE_REF.
- packages/ci-actions/bin/release-notes-generate.mjs: explicitly check
GITHUB_REPOSITORY before splitting, consistent with the other env
var guards a few lines below.
- upcoming-release-notes/relax-release-notes-filenames.md: fix author
casing (matiss -> MatissJanis) so changelog attribution is correct.
* [AI] Reject empty release-note bodies
content.trim().split('\n').length === 1 is true for the empty string
(''.split('\n') returns [''] of length 1), so blank notes slipped past
the single-line check. Reject empty trimmed content explicitly.
* [AI] Resolve PR numbers from commit subjects instead of GitHub's API
parseReleaseNotes was doing one GitHub API round-trip per non-numeric
release-note file. That scales badly for release generation, and the
docs site's generate-upcoming-release-notes.mjs runs on every docs
build — so contributors were hitting the GitHub API (or failing 401
without a token) every time they previewed docs locally.
actualbudget squash-merges every PR through the GitHub UI, which
appends "(#NNNN)" to the resulting commit subject. So:
git log -1 --format=%s -- <path>
plus a /\(#(\d+)\)\s*$/ match recovers the PR number without touching
the network, and works offline / without a GITHUB_TOKEN.
Side effect: switched from "first commit that added this file" to
"most recent commit touching this file", which is what we actually
want — when a file is renamed (e.g. 7907.md -> 7954.md when a wrong
PR number is corrected), the changelog should point at the rename PR,
not the original add. The SHA->PR cache and fetchPrForCommit go away;
no longer needed.
If a file's subject doesn't match (direct push to master, manually
rewritten subject), the entry still emits without a PR-link prefix —
same graceful degradation as before.
* [AI] Pin PR-number lookup to each note's add commit
resolvePrNumber was using git log -1 with no diff filter, returning
the latest commit that touched the file. That's fine until someone
edits an existing release note in a follow-up PR (typo fix, author
correction) — at which point the changelog entry would suddenly
point at the wrong PR.
Add --diff-filter=A so the lookup pins to the commit that originally
added the path. Empirically verified against this repo: renames keep
working (git records a rename as A at the new path when --follow
isn't used), and the edit case now correctly returns the original
add commit instead of the most recent touch.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Actual Budget Community Documentation
This repo is the Actual Budget community documentation website, built using Docusaurus 3, a modern static website generator.
Docusaurus 3 uses Node.js, so if you are running Actual on your local machine, you should be able to easily run Docusaurus 3.
Welcome
Firstly, thank you for stopping by and giving up some of your time to either check out the documentation we have already produced or pick off some of the issues and help create some new documentation for our future users. Check out the guidelines for more information on how the documentation is structured and tips for consistent formatting.
Installation Methods
Actual Budget can be installed on many different platforms. However, at this time, the official Actual Budget documentation only supports the following methods:
- Local Installation (on your own machine)
- Actual-server
- Desktop apps
- Fly.io
- PikaPods
- Docker
If you would like to write documentation for another installation variant, please feel free to continue to do this and host it on your own personal blog, Medium, Tumblr, or any other short-form publication service. We will be more than happy to add a link to that from our documentation. Open a PR and add it to the list in the installation overview.
However, in doing so, you would become responsible for these instructions. If they become out of date or people want in-depth help with them, we will point them to you for assistance if the community is unable to help. If lots of people report issues with them, we may have to remove the link altogether.
Contributing
Please review the contributing documentation on our website: https://actualbudget.org/docs/contributing/
Issues
If you know of a part of Actual that isn't documented and you would like to know more about that part of the software, open an Issue and one of the documentation team will get to it. Or have a go at writing it yourself; we could really use all the help we can get.
Pull Requests
When submitting a pull request, please make sure that your contributions are complete. I am checking this repo regularly, so if I see an open PR, the likelihood of me pulling it and merging it is high.
Documentation submitted will be proofread and amended before merging. Please don't take this personally if any of your documentation gets amended; we just want to make sure all documents are ready to go before merging them into master.
Installing the Docs
Firstly, pull this repo into a local area on your machine, navigate to that directory, and run the following command:
$ yarn
Local Development
To start Docusaurus 3 navigate to the folder where the repo resides from a command prompt and issue the following command.
$ yarn start
This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
Build
$ yarn build
This command generates static content into the build directory and can be served using any static contents hosting service.
Deployment
Using SSH:
$ USE_SSH=true yarn deploy
Not using SSH:
$ GIT_USER=<Your GitHub username> yarn deploy
If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the gh-pages branch.
Writing Good Release Notes
For general guidelines, see Contributing section of the documentation. The Documentation site is not versioned in the same manner as the rest of the project. The Documentation website is more of a living document. Merges into master will have the title and PR# as commit message, with the PR description as extended git commit description.