Release engineering is exhausting so here's cargo-dist
1–10 of 66 posts
Re: Release engineering is exhausting so here's cargo-dist
#2Bend the curve!
Re: Release engineering is exhausting so here's cargo-dist
#3"Alright so I've given you The Pitch of how this should work, but how does it actually work today? Well, yes, I wouldn't announce this if not -- but there's a lot of future work to do! Actually no I take that back, it's definitely perfect. Those familiar with my broader oeuvre know this will absolutely be a perfectly crafted demo that avoids all the sharp corners of cargo-dist!"
One of the most honest paragraphs ever written.
Seriously though, great tool and great write up. I hope something like this lands as an official cargo feature. Coming from mostly Python land at work with crazy dependencies for TF and PyTorch GPU support (On Windows sometimes!) makes me super jealous.
Re: Release engineering is exhausting so here's cargo-dist
#4> Congrats kid you're A Release Engineer now and your life is hell. Enjoy debugging basic typos on a remote machine with 20 minute latency because you sure can't run those Github CI bash-scripts-in-yaml files locally!
Yes! Why is this accepted??
Gitlab has a way of running CI locally (for Docker based builds anyway; who knows about Windows or Mac) but a) it doesn't support the same features at the "proper" one (even basic ones like the `default` key) and b) they deprecated it!
Ok in fairness they've stated in a random comment that they won't remove it before providing an alternative.... But still, how is this not a core feature of all CI systems?
Re: Release engineering is exhausting so here's cargo-dist
#5> Congrats kid you're A Release Engineer now and your life is hell. Enjoy debugging basic typos on a remote machine with 20 minute latency because you sure can't run those Github CI bash-scripts-in-yaml files locally! Yes! Why is this accepted?? Gitlab has a way of running CI locally (for Docker based builds anyway; who knows about Windows or Mac) but a) it doesn't support the same features at the "proper" one (even…
You can run GitHub workflows locally with act: https://github.com/nektos/act
Re: Release engineering is exhausting so here's cargo-dist
#6> Congrats kid you're A Release Engineer now and your life is hell. Enjoy debugging basic typos on a remote machine with 20 minute latency because you sure can't run those Github CI bash-scripts-in-yaml files locally! Yes! Why is this accepted?? Gitlab has a way of running CI locally (for Docker based builds anyway; who knows about Windows or Mac) but a) it doesn't support the same features at the "proper" one (even…
You can run GitHub workflows locally with act: https://github.com/nektos/act
This is far from perfect, IME. The big problem I have (and maybe there's a solution I don't know about) is that there's no easy way to test getting event data, unless you wanna rebuild the events yourself (which is hardly reliable if the problem is something like verifying a conditional that enables/disables a stage).
Re: Release engineering is exhausting so here's cargo-dist
#7Earlier quoted context omitted.
You can run GitHub workflows locally with act: https://github.com/nektos/act
This is far from perfect, IME. The big problem I have (and maybe there's a solution I don't know about) is that there's no easy way to test getting event data, unless you wanna rebuild the events yourself (which is hardly reliable if the problem is something like verifying a conditional that enables/disables a stage).
Seconding this; act has a lot of potential but misses a number of features such as support for deployment environment variables (eg `${{ var.DEPLOY_SPECIFIC_ENV_VAR }}`) and only recently added support for reusable workflows (https://github.com/nektos/act/issues/826). It looks like fine software and the maintainers deserve praise for their work but it's not yet a drop-in replacement for GitHub Actions.
Re: Release engineering is exhausting so here's cargo-dist
#8> Congrats kid you're A Release Engineer now and your life is hell. Enjoy debugging basic typos on a remote machine with 20 minute latency because you sure can't run those Github CI bash-scripts-in-yaml files locally! Yes! Why is this accepted?? Gitlab has a way of running CI locally (for Docker based builds anyway; who knows about Windows or Mac) but a) it doesn't support the same features at the "proper" one (even…
You can run GitHub workflows locally with act: https://github.com/nektos/act
Act is okay, but the runner image behaves quite differently than a GitHub runner would. The original image would just be too big for reasonable local workflows.
Also artifacts don't seem to be supported.
Re: Release engineering is exhausting so here's cargo-dist
#9> Congrats kid you're A Release Engineer now and your life is hell. Enjoy debugging basic typos on a remote machine with 20 minute latency because you sure can't run those Github CI bash-scripts-in-yaml files locally! Yes! Why is this accepted?? Gitlab has a way of running CI locally (for Docker based builds anyway; who knows about Windows or Mac) but a) it doesn't support the same features at the "proper" one (even…
> But still, how is this not a core feature of all CI systems?
Vendor lock-in, presumably.
Re: Release engineering is exhausting so here's cargo-dist
#10> (Did you know the warning you get on Windows isn't about code signing, but is actually just a special flag Windows' builtin unzipping tool sets on all executables it extracts?)
My jaw hit the floor here.