[herczegzsolt]

We're a tiny company, but it is basically "banned" for similar reasons.

We're concerned more and more about GitHubs behavior ever since the Microsoft acqusition. Due to this, we've agreed not to use any proprietary GitHub solution, including codespaces, actions, as well as copilot. It feels like new GitHub features go towards a data-hoarder, vendor lock-in oriented solution.

[taubek]

What is the problem with GitHub actions?

[herczegzsolt]

There's very little guarantee to where the GitHub-provided runners are executed. There's very little guarantee as to what the auto-updating self-hosted runner binary does. There's very little guarantee as to what the GitHub-provided containers and actions contain.

It is also unsupported - and exceptionally hard - to execute runners without GitHub being available, or to migrate off of the proprietary action descriptor format.

Running GitHub enterprise locally may releive some of these issues, but using GitHub.com with GitHub actions is somewhat of a security and reliability nightmare, unless you trust Microsoft's GutHub with infinite visdom and 100% uptime.

[verdverm]

The same thing could be said of any build system unless you run it yourself and invest a lot of effort in locking it down. Then you have to worry a out what is running in your build system... at some point, this all becomes paranoia.

[herczegzsolt]

To some extent I agree, but I see a major difference in whether you have the ability to control it or not.

With GitHub actions, you have to trust the platform or migrate away, there are no other options.

With many more open alternatives, you have the ability to control these. factors if you need or want to. Most likely you wont.