Wow this looks really slick! After ramping up and using Bazel for a bit I'm totally sold on starlark too--it's a breath of fresh air to just use (mostly) python to write all the configuration and infrastructure code. I'm kind of sick of learning some new bespoke, pet language dreamed up to scratch an itch and such--let's just use python and move on to more important things.
My only real gripe with starlark is that the import story is still a bit ugly and unweildly--you have to specify every explicit global function or variable you use, there's no * imports yet. But it's kind of a minor issue in the grand scheme of things.
I love starlark and I love this as a better way to run Github actions.
It's confusing that this is a managed external service. Github Actions are a fully flexible runtime, it feels like you could get away with all this functionality with Actions as the underlying runtime not some third party service.
This was actually made before GitHub Actions were out. This can potentially be converted in the future to function as a GitHub action.
That said - this gives a much faster reaction to events from GitHub as nothing needs to be provisioned before execution. Also allows for much simpler deployment and developemnt.
I discuss this in my EnvoyCon talk, see on repokitteh.io for video.
You mention different goals (from GA) and a will to open source (RK).
The parent user seems to have found a way for you to publicize your business efficiently: a Starlark syntax on top of github actions through your runtime, maybe brought in by the OSS community, giving you ample opportunity to capt this market of developers.
People looking for better Developer UX would pay for faster processes, right?
7 comments
[ 3.0 ms ] story [ 29.2 ms ] threadMy only real gripe with starlark is that the import story is still a bit ugly and unweildly--you have to specify every explicit global function or variable you use, there's no * imports yet. But it's kind of a minor issue in the grand scheme of things.
It's confusing that this is a managed external service. Github Actions are a fully flexible runtime, it feels like you could get away with all this functionality with Actions as the underlying runtime not some third party service.
This was actually made before GitHub Actions were out. This can potentially be converted in the future to function as a GitHub action.
That said - this gives a much faster reaction to events from GitHub as nothing needs to be provisioned before execution. Also allows for much simpler deployment and developemnt.
I discuss this in my EnvoyCon talk, see on repokitteh.io for video.
You mention different goals (from GA) and a will to open source (RK). The parent user seems to have found a way for you to publicize your business efficiently: a Starlark syntax on top of github actions through your runtime, maybe brought in by the OSS community, giving you ample opportunity to capt this market of developers.
People looking for better Developer UX would pay for faster processes, right?
Oh and long live Starlark and so long YAML.
I wish we had this at work!