On 24 April 2018 at 22:43, sebb <[email protected]> wrote: > On 24 April 2018 at 17:18, Jan Iversen <[email protected]> wrote: >> >> >>> On 24 Apr 2018, at 17:29, sebb <[email protected]> wrote: >>> >>> The buildbot job attic-site [1] is now working. >>> >>> It does the following: >>> - checkout attic/site (fresh) >>> - rm -rf docs/projects >>> - runs ./build.sh >>> - svn add docs -force >>> - svn commit (currently disabled) >> Is a svn commit really the only way to update the site ? > > It's only possible to update sites from SVN or Git using the > appropriate pubsub service. > >> Would be nicer if we could just copy the files somewhere. > > AFAIK, not possible. > > A plain directory would not work with pubsub which relies on watching > SVN or GIT commits. > > Only infra have direct access to the webserver files. > >> As I wrote elsewhere I have a talk pending with infra, how the trigger (our >> “real” attic site) will work if we move attic to git >> (Something that again would help edit from anywhere). > > As I already wrote, Buildbot also works with Git. > > For example the ponymail.conf file in the same directory is an example > of git update. > >>> >>> Note that it is necessary to remove the generated files to ensure any >>> deletions are noticed >>> Probably should not happen in the case of Attic, but it would pick up >>> any files that have not got generated for any reason. >>> >>> The builds are listed at: >>> >>> https://ci.apache.org/builders/attic-site >>> >>> The job does not currently seem to send any mails to the attic general >>> list though it is configured do so on changes of status >>> (success/failure). >>> Not sure why; I would have expected some. >>> >>> Let me know when the site is in a fit state to try enabling checkin. >> If you by checkin means overwriting the production site, then as pr my >> review I am -1 on it. > > See below. > >> If you by checking means having the existing production site untouched (very >> important), and site-jekyll, site-lua and site-json somehow below the >> production site, then I do not see the reason why not to commit. >> >> DO NOT touch the production site, before we have a clear decision on which >> of the 3 sites shall replace production. > > I think you misunderstand the purpose of the job. > > It is intended to build the attic/site files and commit them. > Just as we have to do manually at present. > > At present it runs under attic/site so will build on changes to the > sources in xdocs (and if other files eg stylesheets are changed) > > Once it is working for such changes, the commit step can be added.
The buildbot job is now working fine. It detects changes to attic/site and runs the build script. I will enable the commit step. > Then when we decide which alternative (if any) to use, I suggest we > rename attic/site to attic/site-old and rename attic/site-winner to > attic/site. > > So long as there is a build.sh script everything should continue to > work as before. > > Though it might be sensible to temporarily disable the attic-site buildbot. > > Likewise if Attic moves to Git the buildbot should be disabled first. >> My opinion. >> rgds >> Jan I. >>> >>> [1] >>> https://svn.apache.org/repos/infra/infrastructure/buildbot/aegis/buildmaster/master1/projects/attic-site.conf >>> (requires committer karma) >>
