I'm still trying to understand the pieces... On 10/3/16, 9:04 AM, "Christofer Dutz" <[email protected]> wrote: >In github they have these orphan branches to provide content for the >project website separate from the projects code itself. >
And AIUI, the good or bad of that of the orphan branch for Apache projects is whether the release artifact contains the doc or not. I think it isn't necessary to ship our documentation in our source releases so having an orphan branch allows co-location without danger of cross-pollenization. But it sounds like the asf-site branch doesn't have to be an orphan. >You could write a script that generates the HTML content from markup >files with jekyll by explicitly executing the "jekyll" tool and take the >HTML, CSS it produces and put that in the "asf-site" repo. Git supposedly has post-commit hooks or something like that that GH uses to run Jekyll. I was trying to figure out if ASF gitpubsub is using post-commit hooks or not. Or maybe that is part of what BuildBot does? Maybe a post-commit hook is also a script, but it seemed more "integrated" than running Maven from builds.a.o to build our site. Or are you saying that mavin-site-plugin is run from a post-commit hook? I'd prefer if site updates were truly triggered from a commit instead of polled and handled later by CI. > >No matter what tool we would be using, this would have to happen on the >ASF "Buildbot". This is some sort of ASF-built build tool and is not >Jenkins (I thought buildbot was a different name for Jenkins, but it's >not). This Buildbot has the ability to commit to git repos which Jenkins >doesn't seem to be able to do). Currently most projects that need some >further processing use Buildbot to generate their site and so could we. > > >We can setup the content to be staged immediately without having to stage >it first (But it's simply an option that projects can opt in and out to) Thinking about it more, I can probably live with most workflows for the main pages on our site, but I think what we want to achieve is fast and easy updates to the more detailed documentation including asdoc/javadoc. So if we can create asf-site branches in our repos and changes there will automatically map into pages on our site or if it is ok for some of our main pages to point to the ASF repo URLs, then that might be good enough. Do we know if we can serve asdoc/javadoc from the repo URLs? Otherwise frequent updates to asdoc might really burden the buildbot. > > >I think we shouldn't rely on something provided by Github at all. We >should rely only on the ASF Infrastructure. > I agree. It would be nice if somehow our presence on GH was also enhanced by this work. It appears that some projects are trying to use GH pages since that's how most folks discover their project. Is the next step to create an asf-site branch in one of our existing repos and find out if Infra can map it to some subfolder on flex.a.o? Thanks, -Alex
