I'm happy if we can get a .htaccess setup working. pekko.apache.org can have just the home page and some pages like the download page while all other pages are redirected to nightlies.apache.org.
Would it be possible to remove all the pekko core docs (and api/japi) for pekko.staged.apache.org to see how this all works? On Wed, 26 Apr 2023 at 15:19, Johannes Rudolph <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
