Sorry, I missed the point that web sites can only be published if the source files are in Git [1]. If I understand correctly the only thing that the maven-scm-publish-plugin would do is committing the target site to the asf-branch (what we currently need to do manually). So for me 1 & 2 are not mutually exclusive options, but 2 makes 1 actually a lot easier, because then 1 is only a simple Maven goal.
Otherwise the Jenkins job would need to do those SCM operations manually. [1] - https://blogs.apache.org/infra/entry/git_based_websites_available > Am 04.10.2017 um 16:26 schrieb Robert Munteanu <romb...@apache.org>: > > On Wed, 2017-10-04 at 12:16 +0200, Konrad Windszus wrote: >>> On 4. Oct 2017, at 12:11, Bertrand Delacretaz <bdelacretaz@apache.o >>> rg> wrote: >>> >>> On Wed, Oct 4, 2017 at 12:07 PM, Konrad Windszus <konra...@gmx.de> >>> wrote: >>>> ...I prefer 2 to not pollute the Sling Site Git repo with >>>> generated artifacts... >>> >>> But it's *very* useful to be able to see the diffs of the published >>> content before pushing them live. >> >> Once we fixed all bugs in our templates, the diff on the MD source >> files is IMHO enough. > > > I am not sure how 1 would pollute the git repo ... The process right > now is to build the HTML files and resync the asf-site branch with the > output. > > But anyway I think that having a Jenkins job that pushes every change > on the master branch automatically using the maven-scm-publish plugin > would be nice. > > So I would first implement 2) and then 1). And of course we can still > preview changes locally, for larger changes. > > How does that sound? > > Robert