Skip to content

Remove the redundant broken gh-pages deploy job - #188

Merged
caglarpir merged 1 commit into
mapillary:mainfrom
caglarpir:cleanup-deploy
Sep 8, 2026
Merged

Remove the redundant broken gh-pages deploy job#188
caglarpir merged 1 commit into
mapillary:mainfrom
caglarpir:cleanup-deploy

Conversation

@caglarpir

Copy link
Copy Markdown
Contributor

The repo has two workflows publishing to the same gh-pages branch:

Workflow Job Auth Result
main-docs.yml build_docs_job JamesIves/github-pages-deploy-action + automatic GITHUB_TOKEN works — this is what is live
documentation.yml gh-release webfactory/ssh-agent + secrets.GH_PAGES_DEPLOY fails

The second fails on every push to main:

git@github.com: Permission denied (publickey)
fatal: Could not read from remote repository.

The GH_PAGES_DEPLOY key is no longer valid. This has gone unnoticed because the site does still deploy — the other workflow does it, and it needs no configured secret. gh-pages was last updated today, and mapillary.github.io currently serves the Docusaurus 3 build from #186.

Rotating the key would fix a job that is redundant, leaving two workflows racing to publish the same content. So this deletes the gh-release job instead. documentation.yml becomes PR validation only; main-docs.yml stays the single deploy path.

GH_PAGES_DEPLOY is now referenced nowhere and the repo secret can be deleted.

Also removes a hardcoded git identity pointing at a former contributor's personal email address.

Other fixes in the same files

Three of these are more than cosmetic:

  • main-docs.yml deployed from any branch. It triggered on push with no branch filter, and the Deploy step had no condition — so pushing any branch to this repo would publish that branch's docs over the live site. Now scoped to main. (I hit this myself: pushing a test branch to my fork triggered a deploy attempt there.)
  • Node was unpinned in main-docs.yml. Docusaurus 3 requires >= 20; the job relied on whatever the runner happened to ship. That is the same implicit dependency that left documentation.yml stuck on Node 14 until Upgrade Docusaurus 2.0.0-beta.5 → 3.10.2 #186. Both are now pinned to 20.x.
  • main-docs.yml used bare yarn, not --frozen-lockfile, so the deploy could resolve something other than what the lockfile pins. Now matches documentation.yml.

Smaller:

  • Dropped the unused python-version: [3.6] matrix — the job only runs yarn/npm, so it did nothing but label the check (3.6).
  • Dropped sudo apt-get install -y yarn; yarn is preinstalled on ubuntu-latest, and the apt package of that name is a different tool.
  • checkout/setup-node v1/v2v4, clearing the Node 20 deprecation warnings.

Deliberately not changed

The deploy action stays at JamesIves/github-pages-deploy-action@releases/v3. v4 renames its inputs, and this is the only working deploy path — not something to change in the same PR that touches everything around it. Worth a follow-up on its own.

Test plan

  • Both workflow files validated as YAML; triggers and jobs confirmed
  • grep secrets. across .github/workflows/ returns only the automatic GITHUB_TOKEN
  • Locally on Node 20: yarn install --frozen-lockfile succeeds against the committed lockfile and the build produces 50 pages
  • The checks job on this PR exercises the edited documentation.yml. main-docs.yml only runs on push to main, so its first real exercise is the merge — the change there is small and the build command is the same one checks runs.

The repo has two workflows publishing to the same gh-pages branch:

  main-docs.yml     JamesIves/github-pages-deploy-action + the automatic
                    GITHUB_TOKEN                              -> works
  documentation.yml webfactory/ssh-agent + secrets.GH_PAGES_DEPLOY
                                                              -> fails

The second has been failing on every push to main with

    git@github.com: Permission denied (publickey)

because the GH_PAGES_DEPLOY key is no longer valid. It has gone unnoticed
because the site does still deploy - the other workflow does it, and needs
no configured secret.

Rather than rotate the key and end up with two workflows racing to publish
the same content, this deletes the gh-release job. documentation.yml
becomes PR validation only; main-docs.yml remains the single deploy path.
GH_PAGES_DEPLOY is now referenced nowhere and the repo secret can be
deleted.

This also removes a hardcoded git identity pointing at a former
contributor's personal email address.

Other fixes while in these files:

- main-docs.yml triggered on "push" with no branch filter, and its Deploy
  step had no condition, so a push of any branch to this repo would
  publish that branch's docs over the live site. Now scoped to main.
- Dropped its unused "python-version: [3.6]" matrix. The job only runs
  yarn and npm; the value did nothing but label the check "(3.6)".
- Pinned Node 20 explicitly in both workflows. Docusaurus 3 requires
  >= 20 and main-docs.yml was relying on the runner default, which is the
  same implicit dependency that left documentation.yml stuck on Node 14.
- Switched main-docs.yml to "yarn install --frozen-lockfile", matching
  documentation.yml, so the deploy builds what the lockfile pins.
- Dropped "sudo apt-get install -y yarn"; yarn is preinstalled on
  ubuntu-latest and the apt package is a different tool.
- checkout/setup-node v1 and v2 -> v4, clearing the deprecation warnings.

The deploy action itself is left at JamesIves v3 deliberately. v4 renames
its inputs, and this is the only working deploy path, so it is not
something to change in the same PR that touches everything around it.

Verified locally on Node 20: "yarn install --frozen-lockfile" succeeds
against the committed lockfile and the build produces 50 pages.
@meta-cla meta-cla Bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Sep 8, 2026
@caglarpir
caglarpir merged commit e969b58 into mapillary:main Sep 8, 2026
3 checks passed
@caglarpir caglarpir mentioned this pull request Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant