IMHO, generally speaking it’s not just a JS. The declarative approach has its toll we end up having a lot of configurations files instead of having (one or two) normal imperative script
> Then there’s the DevOps and Quality layer. We have roughly 20-30 files for GitHub Actions workflows (lint, test, build, deploy, semantic release), Husky hooks (pre-commit, commit-msg), and pull request templates.
3. Adding GH action integration should be easy , added this to my todo list
4. Yes on the top pipeline structure there is a bit of yaml - it’s only required to reference linear list of jobs - jobs themselves are written in general programming languages . Probably in the simplest form I can even drop this first level yaml … will see , but imho I bit of yaml to structure out the list of jobs is ok, it’s not ok to embed into it action code, shell scripts , etc - to have nightmare of code to maintain and extend … the very idea that dsci is about
So you have cheap vps and want to borrow some free GitHub cpu cycles to do CPU intensive builds ( say compilation ), your GitHub workflow is pretty simple and then all you need us to add your ssh key as a secret to GitHub account so that to deploy artifacts to your VPS … ?
Ok … maybe you do it wrong or at least you don’t need to add your keys to GitHub and compromise security and here the way - reverse cicd:
Also did not find how cicd logic is implemented- no dsl, no scripts , the docs just says it deploys container , vague statement , what does that mean ?