Well, maybe I'm just being dense, but in the most recent two threads you started on this topic, you mention buildbot, and I saw a lot of buildbot traffic come into my mailbox. So apologies if I haven't followed your emails in detail, but I did not see any prior mention of not needing buildbot and could not find your 3-step workflow in previous emails.
On 10/12/16, 12:54 PM, "Christofer Dutz" <christofer.d...@c-ware.de> wrote: >Well I think I wrote down the entire workflow as well as the when's and >why's so many times that I'm not going to repeat them again. > >You don't need the build at builds.a.o at all. I just set that up in the >beginning because in the beginning I thought I would have to trigger >buildbot from there and didn't delete it after finishing, because I >simply forgot it's there. > >What you get is: >- A website in git and not svn. >- The code is generally a lot cleaner. >- You don't have to commit changes to test them in the staging area. >- You don't have to use that stupid web interface to release staged stuff >to production. > >I currently don't have asciidoctor in there at all, so please stop >describing this approach as complicated and simply read my emails. I've been trying to figure out the advantage of using builds.a.o vs buildbot. It sounds like the key point is that we can publish without having to go through the web interface. That sounds like a good deal to me. Let's see what others think. > >Workflow is: > >1. Do changes in the "maven-site" branch >2. Test them locally by running "mvn clean site" >3. Commit and push them > >That's it. Nothing more to it. So assuming others are in favor, what are the remaining steps? Do we want to exactly reproduce the existing site? Do we need to be concerned about the "insecure content" errors/warnings? Nick K was working on a revamp of our website. I wonder how that work will be impacted. Thanks, -Alex
