Take the publish branch from the POM, not the workflow

[slachiewicz]

Found while adding the caller to codehaus-plexus.github.io, which is the one repository that breaks the assumption.

The workflow forces the publish branch:

"-Dscmpublish.scm.branch=gh-pages"

That is correct for project sites. It is wrong for the organisation page: codehaus-plexus.github.io is served from master, not gh-pages —

$ gh api repos/codehaus-plexus/codehaus-plexus.github.io/pages
"source": { "branch": "master", "path": "/" }

— and its POM already says so:

<!-- see https://help.github.com/articles/user-organization-and-project-pages/ -->
<scmBranch>master</scmBranch>

The -D would have overridden that and published the main site to a branch nobody serves. The build would have succeeded, so the only symptom would have been the site quietly never updating.

The fix is to stop overriding it. Parent 26 sets <scmBranch>gh-pages</scmBranch> in pluginManagement, so every project site targets exactly what it did before, and the one repository that needs something different already declares it. That is the same principle already applied to content, which the workflow also leaves to the POM.

My mistake in #62 — I generalised from the fourteen project sites and did not check the org page.

[slachiewicz]

Superseded by #66, which is built on top of this.

The premise here was right — the organisation page is served from master, so the workflow must not force gh-pages. But the first real run showed a deeper problem: maven-scm-publish-plugin ignored the pubScmUrl the workflow passed, because the parent POM sets that parameter explicitly in <configuration> and an explicit value always beats a -D user property. So it kept using the ssh URL, which cannot authenticate with the job token — in any repository, not just this one.

#66 pushes with git directly instead. Once the workflow does the push itself it can no longer read scmBranch from the POM, so the branch becomes an explicit publish-branch input, defaulting to gh-pages.