For testing purposes I added an .htaccess file to the staging version of the website to transparently proxy requests to the documentation and javadoc/scaladoc direclty to nightlies. Seems to work well enough for now so we might be able to postpone setting up more website infrastructure to a later point if necessary.
E.g. https://pekko.staged.apache.org/docs/pekko-http/snapshot/common/marshalling.html https://pekko.staged.apache.org/docs/pekko/snapshot/typed/guide/tutorial_2.html https://pekko.staged.apache.org/api/pekko/snapshot/org/apache/pekko/persistence/DeleteSnapshotsFailure.html https://pekko.staged.apache.org/japi/pekko-http/snapshot/org/apache/pekko/http/scaladsl/model/headers/Access$minusControl$minusExpose$minusHeaders$.html See https://github.com/apache/incubator-pekko-site/issues/6. Johannes On Mon, Apr 24, 2023 at 12:10 PM Johannes Rudolph <[email protected]> wrote: > > Hi PJ, > > it's not completely clear to me why we need a VM to implement either a > push or pull based solution to host the website. > > For a potential push based solution to the standard git-based setup I > already posted a script somewhere that would do the necessary steps. > > For a pull based solution (i.e. have some form of definition which > versions of documentation we want to show at some place), we could > also write a script which pulls together all parts (e.g. from the > nightlies server) and commits them to the git repository. > > A VM to host a static or documentation is not super advanced, but it's > also much more complicated than uploading files to git and having all > the hosting infrastructure maintained from someone else. > > Having the VM build all the documentation does not seem the right > solution for me for various reasons: > * when should the VM start building anything? > * documentation building (Scaladoc, in particular) is the slowest > part of the whole build process, so we will have to optimize to avoid > rebuilding documentation we already have covered > > The only reason I can see why a VM could be useful would be to setup > proper proxying (instead of redirecting) of documentation from > nightlies to the main page if that's what we are looking for. > > Johannes > > > On Sun, Apr 23, 2023 at 6:08 PM Matthew Benedict de Detrich > <[email protected]> wrote: > > > > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
