I removed the static docs/api/japi folder from the staging branch here: https://github.com/apache/incubator-pekko-site/tree/asf-staging/content
The redirection still seems to work. Johannes On Wed, Apr 26, 2023 at 7:07 PM PJ Fanning <[email protected]> wrote: > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
