Web-based documentation should be automatically updated

[Ian Hinder]

We have documentation for Cactus and the ET on their respective websites. This should be updated automatically when the source is changed, so it is never out of date. There should be documentation for the current release as well as the current development version.

There is one technical problem standing in the way of this. The system should be automated, and it needs to have commit rights to a specific directory in the SVN repository hosting the files. SVN accounts for CCT machines tend to be the same as CCT login accounts, so we don't want to store the username and password. I think the best solution is to create an SVN account specifically for the documentation build system which is not tied to a CCT login account. This account would be given commit access to just the directories necessary.

The "checkout, build doc, commit" script should be kept in version control somewhere, and a machine should be chosen on which to run it. It could be run regularly, or just in response to commits.

Keyword: Documentation

[Frank Löffler]

We could always point people to the repositories itself, as long as we keep the pdfs in there and the uploader did actually build a new version (which I hope they did, as they should test what they upload). The downside is that you might often get conflicts on the pdfs. On the other hand, they are very easy to solve.

[Frank Löffler]

Ian - please let me know if the login-info I've sent you works. For others: there is now an account that can be used to automatically push to the ET website.

[Roland Haas]

The web-based docs are now automatically updated once a day by a Jenkins job: https://build-test.barrywardell.net/job/EinsteinToolkitDoc/ and https://build-test.barrywardell.net/job/EinsteinToolkitDocUpdate/ which must be 2 Jenkins jobs to ensure that the provided tarball of HTML files is available for download when the update is triggered on the ET webserver.

CactusCode’s copy is not being updated.