ci: add demo workflow

[sethrylan]

This pull request introduces an automated workflow for generating and updating the demo GIF used in the project README, along with documentation describing the process. The workflow builds the project, starts a Redis instance, populates it with demo data, runs a terminal recording script, and commits the updated GIF to the branch. The documentation explains the demo files and outlines how the workflow operates.

[Copilot]

Pull request overview

This PR introduces automation for generating and maintaining the demo GIF displayed in the project README. The workflow builds the readis TUI Redis browser, populates a Redis instance with demo data, records a terminal session using VHS, and commits the resulting GIF back to the PR branch.

Changes:

• Added GitHub Actions workflow that automates demo GIF generation on relevant file changes
• Added documentation explaining the demo generation process and workflow triggers
• The workflow integrates VHS recording tool with Docker-based Redis setup

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
.github/workflows/demo.yml	Defines the automated workflow that builds the project, sets up Redis, generates the demo GIF using VHS, and commits it back to the PR branch
docs/readme.md	Documents the demo generation process, describing demo.tape and demo.txt files and explaining when the workflow runs

Comments suppressed due to low confidence (7)

.github/workflows/demo.yml:25

• The workflow requires GitHub App credentials (CI_BOT_APP_ID and CI_BOT_APP_PRIVATE_KEY) but there's no fallback or error handling if these secrets are missing. If the secrets aren't configured, the workflow will fail at checkout. Consider adding a conditional check or documentation requirement for these secrets, or use GITHUB_TOKEN as a fallback for repositories where the app isn't installed.

      - uses: actions/create-github-app-token@v2
        id: app-token
        with:
          app-id: ${{ secrets.CI_BOT_APP_ID }}
          private-key: ${{ secrets.CI_BOT_APP_PRIVATE_KEY }}

.github/workflows/demo.yml:43

• The ttyd binary is downloaded directly from GitHub releases without checksum verification. This poses a security risk as the binary could be compromised or the download could be intercepted. Add checksum verification using sha256sum to ensure the integrity of the downloaded binary before installing it.

          curl -fsSL -o ttyd https://github.com/tsl0922/ttyd/releases/download/1.7.4/ttyd.x86_64
          sudo install ttyd /usr/local/bin/ttyd

.github/workflows/demo.yml:80

• The git push command on line 80 doesn't specify which branch to push to. While it will default to pushing to the upstream branch, this could fail if the branch tracking isn't set up correctly. Consider making it explicit with git push origin HEAD or git push origin ${{ github.head_ref }} to be more robust.

            git push

.github/workflows/demo.yml:42

• The workflow uses hardcoded version 1.7.4 for ttyd download. This could become outdated and may not be compatible with future systems. Consider either documenting why this specific version is required, using a variable to make it easy to update, or using the latest release tag if no specific version is needed.

          curl -fsSL -o ttyd https://github.com/tsl0922/ttyd/releases/download/1.7.4/ttyd.x86_64

.github/workflows/demo.yml:53

• The workflow uses redis:latest which is a moving target and could lead to non-reproducible builds if Redis introduces breaking changes. Consider pinning to a specific Redis version (e.g., redis:7 or redis:7.2) to ensure consistent behavior across workflow runs.

          docker run -d --name redis -p 6379:6379 redis:latest

.github/workflows/demo.yml:53

• The workflow starts a Redis Docker container but never stops or removes it. While GitHub Actions cleans up the runner after the job completes, it's a best practice to explicitly stop and remove containers to prevent potential resource issues or conflicts in multi-step workflows. Consider adding a cleanup step or using --rm flag when starting the container.

          docker run -d --name redis -p 6379:6379 redis:latest

.github/workflows/demo.yml:54

• The Redis readiness check lacks a timeout mechanism. If Redis fails to start properly, this loop will run indefinitely, causing the workflow to hang until GitHub Actions times it out (6 hours by default). Add a timeout or maximum retry count to fail fast if Redis doesn't become ready within a reasonable timeframe.

          until docker exec redis redis-cli PING >/dev/null 2>&1; do sleep 1; done

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The documentation references a file demo.txt that doesn't exist in the repository. The workflow directly embeds the Redis commands in the "Populate demo data" step (lines 58-66) instead of reading them from demo.txt. Either create the demo.txt file and update the workflow to read from it, or update the documentation to accurately describe that demo data is defined in the workflow file itself.

Suggested change

	- **[demo.txt](demo.txt)** — Redis commands used to prepopulate the server with interesting demo data. One command per line; blank lines and lines starting with `#` are ignored.
	## CI Workflow
	The [Demo workflow](../.github/workflows/demo.yml) runs automatically on PRs to `main` when relevant files change (`docs/demo.tape`, `docs/demo.txt`, `cmd/**`, `internal/**`, `go.mod`, `go.sum`). It builds `readis`, starts Redis, loads the demo data, runs VHS, and commits the updated `demo.gif` back to the PR branch.
	- **Demo data in workflow** — Redis commands used to prepopulate the server with interesting demo data are defined inline in the [Demo workflow](../.github/workflows/demo.yml).
	## CI Workflow
	The [Demo workflow](../.github/workflows/demo.yml) runs automatically on PRs to `main` when relevant files change (`docs/demo.tape`, `cmd/**`, `internal/**`, `go.mod`, `go.sum`). It builds `readis`, starts Redis, loads the demo data, runs VHS, and commits the updated `demo.gif` back to the PR branch.

[Copilot]

The workflow is triggered on changes to docs/demo.txt, but this file doesn't exist in the repository. Since the demo data is hardcoded in the workflow itself, this trigger path will never activate. Either create the demo.txt file and use it in the workflow, or remove this path from the trigger list.

Suggested change

- 'docs/demo.txt'