AGENTS.md
+34 −1
https://raw.githubusercontent.com/oneuptime/oneuptime/HEAD/AGENTS.md
− An email is read wherever its reader is - on a network without the internet, behind a mail gateway that flags remote images - and every image it fetches tells whoever serves it who opened the email, and when (issue #5124: every email's header loaded its logo from res.cloudinary.com). So an email's own markup loads nothing it does not carry: an image is either inside the email - OneUptime's logo (`oneUptimeLogoUrl`, `packages/Common/Server/Utils/Mail/EmailLogo.ts`) and screenshots go out as inlin+ An email is read wherever its reader is - on a network without the internet, behind a mail gateway that flags remote images - and every image it fetches tells whoever serves it who opened the email, and when (issue #5124: every email's header loaded its logo from res.cloudinary.com). So an email's own markup loads nothing it does not carry: an image is either inside the email - OneUptime's logo (`oneUptimeLogoUrl`, `packages/Common/Server/Utils/Mail/EmailLogo.ts`) and screenshots go out as inlin+ ### Release notes+ Each release's notes on GitHub, which the upgrade guide sends self-hosters to and the website links to as the Changelog, are written by `Scripts/Release/GenerateReleaseNotes.js` from what the release ships: the title of every pull request and the subject of every commit pushed straight to master. So a title is a line someone reads on the release page. Write it as `type(area): what changed, for the person using OneUptime`, not what the code does.+ - `feat`, `fix`, `perf` and `docs` each have a section. `test`, `ci`, `chore`, `refactor`, `style` and `build` go under Maintenance, which is folded, and so does anything in an area of the repository rather than the product (`fix(ci): ...`; `INTERNAL_AREAS` in the script).+ - The scope is the area the line is filed under: use the product's name (`exceptions`, `on-call`, `status-pages`). A title with no type can open with its area instead (`Workflows: every template in five steps`); it goes under New and improved.+ - A `!` after the type or scope (`feat(helm)!: ...`) puts the change under Breaking changes, at the top. Use it whenever an upgrade asks something of the person upgrading.+ - A label wins over a title (`bug`, `enhancement`, `documentation`, `dependencies`), and `ignore` leaves a pull request out.+ To see a release's notes, or write a published release's again:+ ```bash+ GH_TOKEN=$(gh auth token) node Scripts/Release/GenerateReleaseNotes.js --version 14.0.98 --output notes.md+ gh release edit 14.0.98 --notes-file notes.md+ ```+ With `--to master` and no `--version`, it shows what the next release will say.+ ### Continue with Google+ The **Continue with Google** button on the sign-in and sign-up pages runs on a Google OAuth client in Google Cloud, not+ in this repository: merging code turns nothing on, and a server offers the button only once `GOOGLE_SIGN_IN_CLIENT_ID`+ and `GOOGLE_SIGN_IN_CLIENT_SECRET` are set (Helm `googleSignInApp`). Its code is the Google client in+ `packages/Common/Server/Utils/GoogleSignIn` and the provider sign-in it shares with Sign in with Microsoft+ (`packages/App/FeatureSet/Identity/Utils/ProviderSignIn.ts`: who may sign in, the state cookie, the campaign a new+ account keeps). Before changing that code, the button, or anything in Google Cloud, read+ [the Continue with Google guide](packages/Common/Server/Utils/GoogleSignIn/RELEASING.md). It says how to set up the+ consent screen and the OAuth client and their redirect URI, what the button must look like under Google's branding+ rules, how to test it end to end, and which steps only a maintainer may do.+ ### Iron Bank+ The App (its Enterprise Edition), ingress, runner and probe images are also packaged for Iron Bank, the US Department of+ Defense's registry of hardened images (registry1.dso.mil), from `IronBank/App`, `IronBank/Ingress`, `IronBank/Runner` and+ `IronBank/Probe`. Iron Bank's pipeline does not build them: each project's Dockerfile copies what a release's image adds+ (`/usr/src`, and the ingress's nginx configuration, the runner's kubectl, the probe's browsers and Node.js) onto an Iron+ Bank base image of the same distribution, and sets again what the release's Dockerfile sets. So when you change+ `packages/App/Dockerfile.tpl`, `packages/Nginx/Dockerfile.tpl`, `packages/Runner/Dockerfile.tpl` or+ `packages/Probe/Dockerfile.tpl` - a start command, entrypoint, user, environment variable, label or package, or what the+ image copies or builds in - `Tests/Ops/IronBankApp.test.js` or `IronBankProjects.test.js` fails until the project's+ Dockerfile does the same. Before changing anything in `IronBank/`, `Scripts/IronBank/` or `.github/workflows/iron-bank.yml`+ (the "Iron Bank Preflight" workflow), read [the Iron Bank guide](IronBank/README.md).