Helix Pages Service

[tripodsan]

Overview

In order to simplify and unify deployment of helix-pages, we should turn it into a normal service and bypass the normal helix project deployment.

What would need to be changed?

as a first step, we can reuse the existing technology and:

• create a runtime action: pages
• adapt hlx cli to build a unified action that can handle all extensions (due to -1 vote by @trieloff )
• deploy the final action as pages service.
• use the version-lock to set the pages version
• in dispatch invoke the pages action instead of the pipeline action.

What would we gain?

• we can use the same deployment and versioning mechanism like for all other services.
• no weird uuid like packages for helix pages
• we can use package parameters for secrets more easily. (good and bad :-)
• it will be easier to add the universal cloud adapter

[trieloff]

One way to do this:

1. build the helix actions normally using helix-cli
2. deploy them to helix-pages/helix-pages using helix-deploy – each action will be version tagged like [email protected]
3. change the package in helix-config.yaml to helix-pages/helix-pages (instead of the current sha)
4. add an entry to the branch's strain's version-lock: helix-pages: 1.1.3
5. extend helix-dispatch to consider the version-lock for helix-pages when building the action names, so that helix-pages/[email protected] will be used

[tripodsan]

this brings some fundamental changes:

version-lock currently doesn't support packages. so it would be very complicated to map helix-pages/html to helix-pages/[email protected]. so we would need to specify the versions for each script (html, html_plain, etc)

an alternative could be to use package binding for versions in OW:
eg: deploy to helix-pages/1.1.3/* and bind the helix-pages/v1 package to it.

...or, if we deploy to helix-pages/1.1.3/*, we could have a version lock semantics that understands packages: eg: helix-pages/*=1.1.3

---

however, I still think that creating a single action for all extensions would be better. the individual bundles are quite large, so combining them increases deploy time by factor 6. I don't think that concurrency will be a big problem.

so invoking them would just be something like /helix-pages@v1/html?....

[tripodsan]

@trieloff can we consider creating a single multiplex action again? it would:

• + simplify package parameters deployment
• + speed up deployment (1 action vs 5)
• + harmonize how we manage services and service versions
• - increase concurrency of the action invocations