# Discord changelogs through Drone

Active since 2026-10-17: [build #1](https://ci.internet-master.cz/escapists/EscapistsReintroduced/1)
confirmed delivery, and the user confirmed receipt. Drone is the sole sender.
The retired local `tools/discord_changelog.py` exits without sending, including
when invoked with its old arguments.

`.drone.yml` runs a Docker pipeline for pushes to `main`. It tests the notifier,
then reads `CHANGELOG.md` from the pushed commit. Discord receives only the newest
entry's heading and body, plus the last recorded published Workshop version when
available, with mentions disabled and no build, Git or hosting status added.

## One-time setup

1. Connect Drone to Gitea and activate this repository in Drone. A Docker runner
   must be available. Keep the configuration filename at `.drone.yml`.
2. In this repository's **Drone settings → Secrets**, add `discord_webhook_url`.
   Use the existing webhook URL stored locally in `.local/discord-webhook.url`.
   Do not put the URL in Git or enable the secret for pull requests.
3. Push these files to `main`, then verify the `notify-discord` step and its
   corresponding Discord message. Creating the YAML alone does not activate Drone
   or install its Gitea webhook.
4. Keep local/manual notification sending disabled. Do not add a second sender
   or automatically fall back to local delivery after a failed Drone build.

Drone's repository activation manages the Gitea event webhook. This notification
pipeline does not compile, publish or update the mission.

## Updating the changelog

Prepend a new level-two heading and player-facing bullets for each update:

```markdown
## 2026-10-18 — Checkpoint improvements

- Improved checkpoint cover and approach barriers.
- Added a small rest tent and inspection table.
```

Keep headings unique, newest first, with no empty placeholder section at the top.
Use a distinct title for multiple updates on the same date. Entries are plain
Markdown prose/lists; level-three headings are supported. Do not use level-two
headings inside code examples within an entry. Keep the formatted newest entry
within Discord's 2000-character limit; oversized entries fail without truncation.
The dated files in `publishing/` remain separate Workshop release notes.

After compiling/bundling and successfully publishing in Workbench, run:

```sh
python3 tools/workshop_changelog.py --published
```

The helper reads `asset.version` from Workbench's local publishing manifest and
updates `Latest published Workshop version: **0.0.109**` above the changelog
entries. It verifies the addon ID against `addons/core/addon.gproj`. Use
`--manifest /path/to/manifest.json` on another installation. Without `--published`
it only displays the bundle version. The flag confirms that you observed a
successful upload; the helper does not upload or query the Workshop.

Commit that record together with the new player-facing entry and source changes,
then push. Drone reads the version from Git, without needing Workbench files.
Updating only the version does not resend the previous entry. The message labels
it as the last published version, since a Git push can contain newer changes.

The notifier compares `DRONE_COMMIT_BEFORE` with `DRONE_COMMIT_SHA`, covering the
whole push, even when a documentation commit follows the changelog commit.
Unchanged newest entries, historical edits and removing an entry to expose an
older one do not post. Editing the current newest entry posts its revised text.
If a push adds several entries, only the newest is posted. Combine their notes
in one top entry when all changes should appear in the announcement.

The first push introducing `CHANGELOG.md` posts its newest entry. It does not
backfill older release notes. Missing Git history fails instead of guessing a
previous revision; an exact-SHA fetch is attempted for a missing before commit.

## Verification and delivery failures

Run `python3 -m unittest discover -s tests -p test_discord_changelog_ci.py` locally.
Also run `python3 -m unittest discover -s tests -p test_workshop_changelog.py`
for the Workbench version sync.
The tests use temporary Git repositories and mocked HTTP; they send no messages.
`python3 tools/discord_changelog_ci.py --dry-run` inside a Drone checkout with its
normal commit environment prints the selected message without using the secret.

Delivery uses `wait=true` and requires Discord's message confirmation. Errors
fail the step without printing the webhook URL. There are no automatic HTTP
retries. Inspect Discord before manually rebuilding a delivery step: a timed-out
request may already have arrived. Drone workspaces are ephemeral, so rerunning
the same push is not deduplicated across builds; exactly-once delivery is not
claimed.

References: [Drone push triggers](https://docs.drone.io/pipeline/docker/syntax/trigger/),
[repository secrets](https://docs.drone.io/secret/repository/),
[push before commit](https://docs.drone.io/pipeline/environment/reference/drone-commit-before/),
[Discord webhooks](https://docs.discord.com/developers/resources/webhook#execute-webhook).