On 5 May 2018 at 11:48, Hervé BOUTEMY <herve.bout...@free.fr> wrote: > Le samedi 5 mai 2018, 12:00:49 CEST sebb a écrit : >> On 5 May 2018 at 05:25, Hervé BOUTEMY <herve.bout...@free.fr> wrote: >> > Hi, >> > >> > I took time to read the whole discussions from april and understand what >> > was the common objective, and what were solutions envisioned and >> > discussed and partly done and partly with consensus yet to be found. >> > >> > AFAIK, we have a common objective: simplifying attic site maintenance. >> >> +1 >> >> > The simplification ideas and solutions are: >> > - retired site update: >> > banners solution in place with initial site http://oltu.apache.org/ >> > IIUC, there are still some improvements that could eventually be done (for >> > .eu and .us urls), but it works quite well. >> > This idea is the most critical, since it was really a pain for each new >> > project move to Attic >> >> +1 >> >> > - have fewer files to edit: >> > how many files precisely to edit now? >> > evaluation has been that this require changing templating solution (too >> > hard or no knowledge to add such feature to current Ant/Anakia build), >> > and format of data >> > this is where we have 2 competing solutions.. we'll discuss this later >> > >> > - avoiding build tools use on editor's computer: >> > buildbot job added that builds and publish when source is updated. >> > Manual local build and commit can still be done >> > AFAIK, this solution works well >> >> Yes, it works well with SVN. >> >> I have tried to get a GitHub/GitBox-based version working using the >> temporary attic-test repo. >> The build aspect works fine and can use separate branches for source and >> target. > oh, great work! > I see https://github.com/apache/attic-test > but where is the buildbot job, please?
Buildbot config file is the same as for attic-site: https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/attic-site.conf (Note: I am still working on getting attic-test-alt to respond to repo changes) >> >> Unfortunately there is a problem when buildbot tries push the updated >> target workspace back. >> See https://issues.apache.org/jira/browse/INFRA-16471 > I suppose this will be fixed: it works for Jenkins, no reason why it would not > work for buildbot once the setup is fixed Yes, and it will have to be fixed for when projects migrate from git-wip. > in case there are strong issues, we can publish html to svnpubsub: I know the > setup with sources in GIt and output in svn can look surprising, but it works > (sources and output are really something separate) for example for Maven site > (for reasons I won't explain here, but switching output fully to Git was not > an option: we switched only source, to get GitHub edit, then Jenkins build and > commit and svnwcsub to the live site) That should work, and it would avoid having to change the live site publication source. The build attic-test-alt already uses parallel checkouts (rather than re-using the same workdir). It should be simple enough to change the target workdir to use SVN instead of Git and change the SCM commands accordingly. >> >> > - web browser only edit: >> > Idea on this would be to use GitHub online editing: given ASF has GitBox >> > service in place, and with previous automated build and publish on source >> > update, this seems feasible. >> >> I have tried this with attic-test. >> >> AFAICT when using a browser GitHub can only be used to update existing >> files. If there is a way to create a new file, it's not at all obvious, and >> would presumably mean more work. > hehe, it's in the middle of the button bar: look at the little file addition I > just did using it :) D'oh! How did I overlook that? >> >> So a single file solution seems essential to support easy online updates. >> >> > This Git/GitBox/GitHub solution could bring us other advantages: branches >> > management and PR review would ease tests and discussion before deciding >> > to >> > merge to trunk/master >> > >> > >> > IMHO, working on GitBox/GitHub solution would ease future work and >> > discussion on the "have fewer files to edit" ideas. >> > And I know that it is feasible without changing many things on the current >> > situation. >> > >> > WDYT about prioritizing this Git/GitBox/GitHub solution? >> >> AFAICT that will not allow browser-only addition of new Attic projects >> unless the code is also changed to support using a single file as the >> data source. It would allow maintenance of existing templates etc, >> i.e. could be used to update existing project info or change >> templates. >> >> But if we do wish to move the existing site to Git first, most of the >> preparatory work for automatic builds has been done using the >> attic-test repo. > thank you, this was exactly what I expected to be done with this test repo > Just need to have a link to the buildbot job > And ideally some explanations on the way the output Git commit is done (is > there some source somewhere?): it's for me the opportunity to learn more about > buildbot See the attic-site.conf file (URL above) >> >> However until INFRA-16471 is solved, Buildbot cannot be used to >> automate site publication with GitBox/GitHub. > I expect this will be fixed soon... > or if really there is an issue, we'll use svnpubsub for output: the only > drawback is that it hurts people when you mix Git for source and Svn for > output... Documentation is key here. >> >> Note: pushes to git-wip repos work fine under Buildbot, however I >> think it would be a non-starter to move to git-wip as it is being >> phased out and we would have to move to Gitbox later anyway. >> >> > Regards, >> > >> > Hervé > >
