Skip to content

Confirm the site redeploys from the tagged commit on the first release #39

Closed

Description

@Mearman

The redeploy-site job in ci.yml starts the Pages workflow again after a release, so the explorer's footer links to the release page rather than the commit. It runs only when the Release job's Record whether a release was cut step finds a tag on HEAD, which only a release gives, so it has not run for real yet. Merging the explorer's PWA changes (#37, #38) released nothing, and the job was skipped.

What has been checked without a release: actionlint and zizmor pass on the workflow, a build in a clone with a release tag on HEAD gives a release identity with a releases/tag/ link, and the site deploys from main as a commit identity today.

Deferred until the first release after #37. Then confirm that redeploy-site ran, that a Pages run started from the tagged release commit, and that the footer at https://exadev.github.io/combinatrix/ shows v<version> linking to that release. If gh workflow run is refused with the job's token, the job needs a different way to start the workflow.

Activity

  1. Mearman commented on Oct 30, 2026

    @Mearman
    MemberAuthor

    Confirmed on the release of 2.1.0 (from #40): the Release job cut v2.1.0, redeploy-site ran and succeeded, the job's token was accepted by gh workflow run, and a Pages run started by workflow_dispatch from the release commit 566976f deployed. The footer at https://exadev.github.io/combinatrix/ now shows v2.1.0 linking to https://github.com/ExaDev/combinatrix/releases/tag/v2.1.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    deferredIdentified work not started now

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions