> I raised an INFRA JIRA [1] in the hope that we could get a rsync server that we could use to deploy the pekko.apache.org web site. They have suggested instead that many ASF teams have their own VMs that they use to host their web sites.
I think this answer reflects the fact that most Apache projects act as a mono repo whereas Pekko is quite unique in that we have a multi repo setup. If you have a mono repo setup then a VM can definitely make sense but the reason why I was suggesting rsync is that it greatly trivializes our setup when it comes to docs, i.e. every for every pekko git repo * For merge on PR we can rsync the docs onto nightlies * For actual release we just rsync the docs onto the main central location that hosts the site One of the other reasons behind the trivialization is that its granular, i.e. we can have different release cycles with the different pekko git repos and they can each rsync to the VM on their own accord when a release is made. > If we have a VM, we could git pull on all our repos and have a script that builds all the paradox docs, scaladoc and javadoc and copies the results to a dir structure that Apache HTTP Server or some similar app serves as a web site. We could get the INFRA team to set up a CNAME mapping for this. > Is this approach ok? If anyone has any alternative suggestions, please keep in mind that we need to work with ASF INFRA and other ASF teams and need solutions that work with what those other teams can facilitate. Unless I am missing something, if we have setup our own VM what is actually preventing us from rsyncing to that VM as part of our process rather than having to deal with making a custom setup of pulling every necessary git repo? If this kind of flow is is a hardline, sbt has a less well known but incredibly useful feature in that it supports dynamic projects based on git uri, i.e. https://alvinalexander.com/scala/using-github-projects-scala-library-dependencies-sbt-sbteclipse/ . In other words, we can create a master sbt build that references every other pekko git repo by its actual git uri as well as handling pulling, i.e. lazy val core = ProjectRef(uri("[email protected]:apache/incubator-pekko.git"), "pekko") lazy val http = ProjectRef(uri("[email protected]:apache/incubator-pekko-http.git"), "pekko-http") ... And then since you can represent each project as a value referenced by its git repo you can just do http/docs/paradox and it will generate the docs from that git [email protected]:apache/incubator-pekko-http.git repo. We still have the issue that we need to make sure we clone the projects at the correct hash that points to the release (which is yet another reason why I like the rsync setup because it can be done at the same time an actual release is being made). I still do however take the point you made earlier in that we shouldn't over engineer the docs setup because it's strictly not necessarily needed for release and we have a lot of other pressing issues but the main takeaway that I want to drive home is that our setup with Pekko is not like other Apache projects and this is why I am trying to encourage processes that work best with the setup we have at hand (which is multi module git setup). For that reason I am perfectly happy with having a more manual solution and we can suspend doing a more proper solution when timing is more appropriate On Fri, Apr 21, 2023 at 4:54 PM PJ Fanning <[email protected]> wrote: > Hi everyone. > > I raised an INFRA JIRA [1] in the hope that we could get a rsync server > that we could use to deploy the pekko.apache.org web site. They have > suggested instead that many ASF teams have their own VMs that they use to > host their web sites. > > If we have a VM, we could git pull on all our repos and have a script that > builds all the paradox docs, scaladoc and javadoc and copies the results to > a dir structure that Apache HTTP Server or some similar app serves as a web > site. We could get the INFRA team to set up a CNAME mapping for this. > > We could keep the script(s) that build the web site in git for safety - > allowing us to rebuild the VM easily if we lose the pre-existing VM. > > Is this approach ok? If anyone has any alternative suggestions, please > keep in mind that we need to work with ASF INFRA and other ASF teams and > need solutions that work with what those other teams can facilitate. > > Regards, > PJ > > [1] https://issues.apache.org/jira/browse/INFRA-24453 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* [email protected]
