attic-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: idea for site maintenance simplification
Date Sat, 05 May 2018 11:10:37 GMT
On 5 May 2018 at 11:48, Hervé BOUTEMY <herve.boutemy@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.boutemy@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é
>
>

Mime
View raw message