You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we add an azure variant, and a gradle variant, and various other modules, each one adds exponentially to the build time. This isn't really scalable past a certain point.
A more scalable approach would be to re-architect and dynamically generate each combination in the UI when people ask for it. That is infinitely scalable, but it's not very dog-foody to use Javascript rather than Java to render the asciidoc. A backend server would be dogfoody, but involve the complexities of hosting.
I think it might work - at the expense of some complexity - to got a hybrid approach, with progressive creation. The base build would create the base variant, and deploy it, and then spin off child builds which would add the other variants as they're prepared. If someone visits a link for a page that doesn't have asciidoc, a holding page at that endpoint would dynamically render.
We could also say some variants are only rendered dynamically on most builds, to try and manage how much github runner time we use. For example, mostly-dynamic should be fine on most PR previews.
The text was updated successfully, but these errors were encountered:
As we add an azure variant, and a gradle variant, and various other modules, each one adds exponentially to the build time. This isn't really scalable past a certain point.
A more scalable approach would be to re-architect and dynamically generate each combination in the UI when people ask for it. That is infinitely scalable, but it's not very dog-foody to use Javascript rather than Java to render the asciidoc. A backend server would be dogfoody, but involve the complexities of hosting.
I think it might work - at the expense of some complexity - to got a hybrid approach, with progressive creation. The base build would create the base variant, and deploy it, and then spin off child builds which would add the other variants as they're prepared. If someone visits a link for a page that doesn't have asciidoc, a holding page at that endpoint would dynamically render.
We could also say some variants are only rendered dynamically on most builds, to try and manage how much github runner time we use. For example, mostly-dynamic should be fine on most PR previews.
The text was updated successfully, but these errors were encountered: