federated repository / milo folder for io runtime actions

[npeltier]

Hi,

reviving some rather old idea i rediscussed recently with @jedjedjedM & @honstar, that is to have common codebase for our runtime actions, as there is a lot of duplication of code (i heard about sharepoint auth) & effort (CDN reverse proxies configurations, registration, validation, ...).
I guess we could make that place public with the right amount of anonymization / obfuscation, so we could have it sit very close to milo (in milo?) codebase

wdyt?

[mokimo]

I would love to host more use-cases and have a more centralized way of deploying things as well. If we have a good automated deployment process around this, it will also make it easier to contribute changes for the larger community

[npeltier]

Yes! it feels a bit like redundancy with you & i talking in https://github.com/orgs/adobecom/discussions/2808 ;) but here with https://github.com/orgs/adobecom/discussions/3304 we have a direct use case.
Should we try right away with

• some folder in milo ? "io.actions" ? (first choice if nobody shouts),
• or another repository "io.actions" within adobecom organization?

[Ben-Zahler]

@npeltier @mokimo for the APC partner portal, we do have an automated way of deploying runtime through CircleCi on every merge to stage branch.
I don't think it makes sense to have a common repo with milo as our project is now with ATS, but @zagi25 who wrote most of the code for the CircleCi integration is joining milo-core team in the next days.

[npeltier]

thanks @Ben-Zahler , is it in the app inventory?

[hparra]

@npeltier are you suggesting a common package? monorepo? single namespace? how many namespace and actions total?

I would make it another repo instead of putting in milo. ci/cd is too different from milo. code patterns may be too. we can officially use typescript with app builder now.

if we do it on github.com we can use workflows instead of circleci. mostly pros. overall, i think making it public is a vulnerability. i feel this way about milo as well.

builds/deploys get annoying after 20+ actions. there are a few optimizations that app builder have not implemented yet. you will bump into them with code sharing patterns. one recommendation is that we sync on all acom app builder-based efforts so we can make asks of platform as an org.

[npeltier]

as per your build / deploy interesting feedback, i guess we are not obliged to build / deploy all actions everytime, right?

[mokimo]

There wouldn't be anything wrong with hosting this as a private repo within adobe/adobecom either IMO. The EDS folks do this for some of their more concerning backend services, it might be easier to have all of the backend services private given that they might carry more security concerns.

FE Code is all obvious on a client anyway and not safe by design, hence 99% of the time there is no question of wether milo code can be public or not.

[npeltier]

fine by me, are we already paying for adobecom private repos?

[npeltier]

ha it looks like it, yes :)

[npeltier]

i'll take care of this on monday then :)

[honstar]

I think we are looking at 2 dimensions of potential federation here:

• develop and publish common utility code via npm modules
• find and host milo-related I/O runtime actions within the milo codebase itself

I'm +1 for the first idea. However, I don't really see an advantage of keeping all related I/O runtime actions within a single repository. While it would make it easier to discover what's available from a code perspective, backend services on I/O runtime are typically non-public, integrated with CircleCI+Vault.

[npeltier]

Thanks @honstar, it makes sense indeed to separate concerns.

What i like with the "second dimension" of hosting actions in the same place, is to federate configurations around the actions (deployment, CDN configurations, self discoverable inventory, ...) but we could start with the first one indeed :)

For the first one, should it be public? should it be a separate repo?

[honstar]

For the first one, should it be public? should it be a separate repo?

I'd lean towards a private repo.

[npeltier]

any wishes about the name?

[jedjedjedM]

"lager" if you want to carry on the dog name tradition

[sukamat]

Hi Nicolas. I see 3 different aspects to this:

1. Hosting AIO actions
2. Deploying AIO actions
3. Common modules like Sharepoint CRUD operations, MSAL authentication etc.

For#1 - It depends. If you are implementing a simple action, then perhaps it can live in a single "App Builder" AIO app project that hosts other simple actions. But complex AIO applications like miloc, floodgate, graybox etc. have multiple actions (web enabled, web disabled, scheduled actions etc.) which will benefit from remaining in separate repos. 2 of the 3 apps above are hosted under github.com/adobecom org.

For#2 - An "App Builder" project comes with its own deployment script (yaml) when you set up the initial AdobeIO project. This is pretty straight forward to use as it uses OOTB github actions workflow, OOTB github secrets to hold any private data and OOTB github env variables required when different data is needed to deploy to AIO dev vs stage vs prod.
AIO projects hosted in git.corp have to use Vault and CICD for handling AIO action deployments as there is no access to Github Actions.

For#3 - I agree there is a need for this. But with the move happening to DA next year, not sure if it will be worth refactoring for SharePoint CRUD operations or MSAL authentication. May be there are other modules that are common enough to be packaged and deployed to npm to re-use across AIO projects.

[npeltier]

right, it's not for SP modules :) but generic needs we could have, i'll start #3 (or Honwai's #1 :p ) as mentionned earlier, and see where it goes