search

apache / pekko-sbt-paradox

Theme and sbt-paradox settings used by Pekko projects
https://pekko.apache.org/
Apache License 2.0
4 stars 6 forks source link

consider putting static content (CSS etc.) in CDN #84

Open pjfanning opened 8 months ago

pjfanning commented 8 months ago

The problem with this plugin is that we need to merge changes and then vote on releases etc. Then after that, we need to uptake it in all our git repos.

If we deploy changes to pekko.apache.org (https://github.com/apache/incubator-pekko-site commits are deployed to an Apache CDN) - then we could have the CDN URLs hardcoded in this plugin. In this approach, a CSS change only needs to be deployed once instead of us having to uptake it in multiple git repos.

samueleresca commented 6 months ago

In terms of next steps for this one:

  1. Move the assets folder to the incubator-pekko-site project
  2. Make sure the assets are deployed in the CDN
  3. Update the current repo incubator-pekko-sbt-paradox to point to the static assets in https://pekko.apache.org
  4. Update the incubator-pekko-site repo to point the deployed assets in the CDN

Is my understanding right? I should have time during these holidays to look into this.

pjfanning commented 6 months ago

In terms of next steps for this one:

  1. Move the assets folder to the incubator-pekko-site project
  2. Make sure the assets are deployed in the CDN
  3. Update the current repo incubator-pekko-sbt-paradox to point to the static assets in https://pekko.apache.org
  4. Update the incubator-pekko-site repo to point the deployed assets in the CDN

Is my understanding right? I should have time during these holidays to look into this.

These steps are about right. We use the main branch of incubator-pekko-sbt-paradox for PRs and commits but merging the main branch to the asf-site branch kicks off an ASF Infrastructure job that copies the files to the apache.org CDN.

pjfanning commented 6 months ago

https://github.com/apache/incubator-pekko-site/wiki/Manual-Publishing#incubator-pekko-site

I'm happy enough for an ASF contributor to temporarily take over the asf-staging branch and making commits directly to it - via PRs if they prefer. Anything merged to the content folder of that git repo will be pushed to https://pekko.staged.apache.org. The point of that staged website is to allow some experimental changes.

We can reset the history on asf-staging branch when we have finished the experimentation.

samueleresca commented 6 months ago

https://github.com/apache/incubator-pekko-site/wiki/Manual-Publishing#incubator-pekko-site

I'm happy enough for an ASF contributor to temporarily take over the asf-staging branch and making commits directly to it - via PRs if they prefer. Anything merged to the content folder of that git repo will be pushed to https://pekko.staged.apache.org. The point of that staged website is to allow some experimental changes.

We can reset the history on asf-staging branch when we have finished the experimentation.

Ok, I should have time in the next few days. I will proceed by doing the changes as PR targeting main. Once merged, try them on the asf-staging branch

pjfanning commented 6 months ago

I'd prefer not to put experimental changes in main. I prefer using asf-staging as the experimental branch.

mdedetrich commented 6 months ago

https://github.com/apache/incubator-pekko-site/wiki/Manual-Publishing#incubator-pekko-site

I'm happy enough for an ASF contributor to temporarily take over the asf-staging branch and making commits directly to it - via PRs if they prefer. Anything merged to the content folder of that git repo will be pushed to https://pekko.staged.apache.org. The point of that staged website is to allow some experimental changes.

We can reset the history on asf-staging branch when we have finished the experimentation.

There is a way to properly fix this, its with a sbt-plugin akin to https://github.com/sbt/sbt-ghpages . The sbt-ghpages plugin already handles the logic of "publishing the generate site to a separate branch", it just needs to be modified to handle asf site specifics.

samueleresca commented 6 months ago

https://github.com/apache/incubator-pekko-site/wiki/Manual-Publishing#incubator-pekko-site I'm happy enough for an ASF contributor to temporarily take over the asf-staging branch and making commits directly to it - via PRs if they prefer. Anything merged to the content folder of that git repo will be pushed to https://pekko.staged.apache.org. The point of that staged website is to allow some experimental changes. We can reset the history on asf-staging branch when we have finished the experimentation.

There is a way to properly fix this, its with a sbt-plugin akin to https://github.com/sbt/sbt-ghpages . The sbt-ghpages plugin already handles the logic of "publishing the generate site to a separate branch", it just needs to be modified to handle asf site specifics.

@mdedetrich Could you please confirm if I'm thinking in the right direction:

  1. Enable sbt-ghpages on main branch with the following configs:
git.remoteRepo := "git@github.com:apache/incubator-pekko-site.git"
ghpagesBranch := "asf-staging" // targeting staging branch
  1. Run (potentially throght the github actions) sbt ghpagesPushSite to publish the content in https://pekko.staged.apache.org/
  2. Once verifyied the asf-staging branch proceed by merging changes in asf-site. Still manual, which it makes sense
pjfanning commented 6 months ago

This is not what those branches are for. asf-staging is for deploying pekko.staged.apache.org. The idea is that a human verifies that pekko.staged.apache.org looks ok before any changes are pushed to asf-site (which leads to a deploy for pekko.apache.org.

Can we separate the discussion about sbt-ghpages into a separate discussion?

samueleresca commented 6 months ago

This is not what those branches are for. asf-staging is for deploying pekko.staged.apache.org. The idea is that a human versifies that pekko.staged.apache.org looks ok before any changes are pushed to asf-site (which leads to a deploy for pekko.apache.org.

Can we separate the discussion about sbt-ghpages into a separate discussion?

I'm proceeding by creating an issue for this in incubator-pekko-site

Roiocam commented 6 months ago

AFAIK, this project only produces the sbt plugin of Paradox. If we have to add a feature or fix a bug, we can do something like #32. After the issue is completed, how can we make the change to Paradox?

pjfanning commented 6 months ago

We can make releases of the jars related to this repo. It requires votes but we have released 1.0.0 in the past. We will need a new release in the next month or 2.

We also publish snapshot versions of the jars after every merge to main branch. We use the snapshot jars in a couple of places - but this is not ideal.

Roiocam commented 6 months ago

We can make releases of the jars related to this repo. It requires votes but we have released 1.0.0 in the past. We will need a new release in the next month or 2.

Thanks the answer from @pjfanning, but i mean how can we made the change to Paradox via coding, e.g. Fix this issue: https://github.com/apache/incubator-pekko/issues/975

Roiocam commented 5 months ago

but i mean how can we made the change to Paradox via coding, e.g. Fix this issue: apache/incubator-pekko#975

I got the answer from https://github.com/apache/incubator-pekko-sbt-paradox/pull/86#issuecomment-1868531722

I am fine with that.