Le samedi 5 mai 2018, 13:10:37 CEST sebb a écrit : > 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 I didn't knaw that: I'll add this link to process.xml internal information on buildbot job
> > (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. as you wish we'll decide later, when we decide if we do the real move of production and precisely with which steps > > >> > - 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? I had to look twice to find it: the first time I looked, I came to the conclusion that you were right, then I came back because "GitHub people can't have missed this feature..." :) Notice: when you see how basic things like this can bring misunderstanding, imagine what happens when it's more complex... > > >> 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. +1 > > >> 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é
