Skip to content

feat(ci): push add-on snapshots to history branch instead of main, fixes #74#75

Merged
stasadev merged 1 commit into
mainfrom
20260519_stasadev_history
May 19, 2026
Merged

feat(ci): push add-on snapshots to history branch instead of main, fixes #74#75
stasadev merged 1 commit into
mainfrom
20260519_stasadev_history

Conversation

@stasadev
Copy link
Copy Markdown
Member

The Issue

Automated add-on updates were committed directly to main, making it hard to distinguish manual changes from bot-generated snapshot noise and leaving main open to direct bot pushes.

How This PR Solves The Issue

  • Before running Go, fetch _addons/ from origin/history into the index so the degradation check can diff against the previous snapshot
  • After Go regenerates _addons/, commit it to the history branch via a git worktree (no branch switching in the main worktree)
  • Same-day re-runs amend the existing snapshot commit and force-with-lease push instead of creating a duplicate
  • Restore commands in the degradation check updated from git checkout HEAD to git checkout origin/history
  • Build job fetches _addons/ from origin/history before Jekyll runs so it always builds from the latest snapshot regardless of skip flags
  • Bump all GitHub Actions versions (checkout, pages, artifact, deploy)

Manual Testing Instructions

Trigger the workflow via workflow_dispatch and verify:

  • history branch receives a chore(add-ons): snapshot YYYY-MM-DD commit
  • main branch receives no new bot commits
  • GitHub Pages deploys successfully with full add-on data
  • Re-running on the same day amends rather than adds a second commit

Automated Testing Overview

No automated tests - this is CI/CD pipeline logic only.

Release/Deployment Notes

The history branch must exist and contain _addons/ before this workflow runs (already satisfied: branch was seeded in commit 6b44bc0).

## The Issue

- Fixes #74

Automated add-on updates were committed directly to main, making it
hard to distinguish manual changes from bot-generated snapshot noise
and leaving main open to direct bot pushes.

## How This PR Solves The Issue

- Before running Go, fetch `_addons/` from `origin/history` into the
  index so the degradation check can diff against the previous snapshot
- After Go regenerates `_addons/`, commit it to the `history` branch
  via a git worktree (no branch switching in the main worktree)
- Same-day re-runs amend the existing snapshot commit and
  force-with-lease push instead of creating a duplicate
- Restore commands in the degradation check updated from
  `git checkout HEAD` to `git checkout origin/history`
- Build job fetches `_addons/` from `origin/history` before Jekyll runs
  so it always builds from the latest snapshot regardless of skip flags
- Bump all GitHub Actions versions (checkout, pages, artifact, deploy)

## Manual Testing Instructions

Trigger the workflow via `workflow_dispatch` and verify:
- `history` branch receives a `chore(add-ons): snapshot YYYY-MM-DD` commit
- `main` branch receives no new bot commits
- GitHub Pages deploys successfully with full add-on data
- Re-running on the same day amends rather than adds a second commit

## Automated Testing Overview

No automated tests — this is CI/CD pipeline logic only.

## Release/Deployment Notes

The `history` branch must exist and contain `_addons/` before this
workflow runs (already satisfied: branch was seeded in commit 6b44bc0).

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@stasadev stasadev merged commit dbf6851 into main May 19, 2026
2 of 3 checks passed
@stasadev stasadev deleted the 20260519_stasadev_history branch May 19, 2026 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Implement the same technique as in sponsorship-data with history branch

1 participant