Skip to content

Push the site with git instead of maven-scm-publish-plugin - #66

Merged
slachiewicz merged 1 commit into
masterfrom
fix/site-workflow-auth
Aug 8, 2026
Merged

Push the site with git instead of maven-scm-publish-plugin#66
slachiewicz merged 1 commit into
masterfrom
fix/site-workflow-auth

Conversation

@slachiewicz

Copy link
Copy Markdown
Member

The first real run failed, on codehaus-plexus.github.io:

[INFO] Checking out the pub tree from scm:git:git@github.com:codehaus-plexus/codehaus-plexus.github.io.git
[INFO] Executing: git clone --branch master 'slachiewicz:********@github.com:codehaus-plexus/...'
[ERROR] ssh: Could not resolve hostname slachiewicz: Temporary failure in name resolution

Why my approach could never have worked

The workflow passed -Dscmpublish.pubScmUrl=…https… to force an https URL. The plugin ignored it and used the ssh URL from scm.developerConnection.

That is Maven plugin parameter precedence: the parent POM sets

<pubScmUrl>${project.scm.developerConnection}</pubScmUrl>

explicitly in <configuration>, and an explicitly configured value always beats the ${scmpublish.pubScmUrl} user property. So the -D was silently discarded — no warning, no error, just the wrong URL. This would have failed identically in all fifteen repositories; the org page was simply the first one tried.

Good argument for the dry-run input, which is how this surfaced without anything being published.

The fix

Maven still builds the site — that part was never the problem. Only the push changes:

  1. clone the target branch with the job token over https
  2. rsync -a --delete the built site over it, so pages deleted upstream disappear from the published site too, which is what scm-publish did for us
  3. commit and push, or, on a dry run, print what would change and stop

No plugin URL resolution involved, and every step is readable in the workflow.

publish-branch input

This also replaces #65, which I opened an hour ago to make the branch come from the POM. That was the right instinct — the org page is served from master, not gh-pages — but the wrong mechanism, since the workflow now does the push itself and cannot read scmBranch out of the POM.

So it is an explicit input, defaulting to gh-pages. codehaus-plexus.github.io passes master. #65 is superseded; I'll close it.

Unexplained, and now moot

The clone URL came out as slachiewicz:********@github.com: — maven-scm injected a username from somewhere I could not identify on a clean runner. It does not matter under the new approach, but I am flagging it rather than pretending I understood it.

Please dry-run again after merging

Callers need no change except codehaus-plexus.github.io, which needs publish-branch: master — I'll update that PR.

The first real run failed. maven-scm-publish-plugin ignored the
pubScmUrl passed on the command line and used the ssh URL from
scm.developerConnection, which cannot authenticate with the job token:

  Checking out the pub tree from scm:git:git@github.com:codehaus-plexus/...
  ssh: Could not resolve hostname ...

The cause is Maven plugin parameter precedence. The parent POM sets
pubScmUrl explicitly in <configuration>, and an explicitly configured
value always wins over the ${scmpublish.pubScmUrl} user property, so
the -D was silently discarded. The approach could not have worked in
any repository.

The build step is unchanged - Maven still generates the site. Only the
push is different: clone the target branch, mirror the built site over
it with rsync --delete so pages removed upstream also disappear, then
commit and push with the job token over https. Every step is visible in
the workflow rather than depending on how a plugin resolves a URL.

Also replaces branch guessing with an explicit publish-branch input,
defaulting to gh-pages. codehaus-plexus.github.io passes master,
because an organisation page is served from there.

dry-run now reports what would change and exits before committing.
@slachiewicz
slachiewicz merged commit f227dcd into master Aug 8, 2026
slachiewicz added a commit that referenced this pull request Aug 8, 2026
The first successful run got as far as listing what it was about to
publish and then died with exit 141:

  M  apidocs/org/codehaus/plexus/util/StringUtils.html
  ...
  ##[error]Process completed with exit code 141

141 is SIGPIPE. The listing was "git status --short | head -50"; head
exits after 50 lines, git status is killed writing to the closed pipe,
and under `set -o pipefail` that becomes the exit status of the whole
pipeline, which `set -e` then treats as fatal.

It only shows up when the output exceeds the pipe buffer, so a small
site would have published fine and a large one would not - plexus-utils
regenerates thousands of apidocs files.

Uses sed, which reads to end of input rather than exiting early, and
reports how many files were truncated from the listing.

Nothing was published in the failed run: the step died before the
commit. The clone, the token authentication and the rsync all worked,
so the fix in #66 is sound.
@slachiewicz slachiewicz added the build Build, CI and release infrastructure label Aug 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

build Build, CI and release infrastructure

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant