[IshKebab]

> 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?

[capableweb]

CircleCI solved this so many years ago, allow users to SSH into the environment the build happens.

Workflow is something like:

- Guess together a random CI or CD workflow, this is just to kick off the process. You can also start with a empty config.

- Something fails, get SSH host+port to connect to

- Enter environment and manually do everything you want to be able to automatically do

- Execute `history` and copy output, trim it into something nicer and put in your config

[sedatk]

You can run GitHub workflows locally with act: https://github.com/nektos/act

[ollien]

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).

[adrienthebo]

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.

[frodowtf]

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.

[netr0ute]

> The original image would just be too big for reasonable local workflows.

Is there a way so I can still do this? I have terabytes of SSD just waiting to be used.

[brundolf]

What we need is a standard CI language/config format across vendors (stuffing a custom DSL inside YAML doesn't count)

That would allow for a tooling ecosystem of static checkers, offline runners, IDE integrations, etc etc, and would also cut down on the learning barrier every time you switch to a new company that uses a different vendor

[wizzwizz4]

> But still, how is this not a core feature of all CI systems?

Vendor lock-in, presumably.

[WorldMaker]

In multiple directions, too. It's easier to build the CI system itself if you are only targeting one class of servers/one means of hosting servers/one specific "cloud".

[nsteel]

If you just want to solve fundamental build issues (rather than say, uploading artefacts etc), I open a PR, make the silly small edits/experiments using the in-browser file editor, then it runs the CI each time. If I ever get it working, I then squash all the crappy debug I did to get there. Miles from ideal but a slight improvement.

[angio]

If you're using nix to build your repo, it's worth adding scripts for releases etc and run them locally and as part of the ci https://determinate.systems/posts/nix-github-actions