5 ms·

no that's not how it works at all. The "actions" are proprietary to GitHub and hosted on GitHub. People create custom actions and allow others to reuse them. Ev

no that's not how it works at all. The "actions" are proprietary to GitHub and hosted on GitHub. People create custom actions and allow others to reuse them. Everything is hooked in to GitHub via their proprietary yaml config. > Not sure why it would be different for GitHub Actions. because vendor lock-in. GitHub doesn't want to make it easy for you to switch.

greggman3 5y ago
You can run github actions offline https://github.com/nektos/act https://github.com/nektos/act I don't think github is trying to create lock-in, I think rather they were trying to make a way to easily share actions (not sure what other CIs systems are designed to have an ecosystem of publicly shared actions). The actions are public and therefore easy to make something that interprets them. I can only guess at some point there will be a push for CIs to converge on some "actions" standard, maybe?
- tyingq 5y ago
  That's neat, though it is a 3rd party trying to replicate it. Gitlab's open source runner supports parsing the ci yml and running a job locally, presumably using the same code as the platform, like: gitlab-runner exec docker some-job-name Though they would both suffer on any dependencies on platform hosted environment vars, secrets managers, etc.
misnome 5y ago
Are there any CI/CD metasystems that aren't vendor locked-in? GitHub/even GitLab, Jenkins (freestyle and scripted)/Azure/Travis.... all vendor-specific, as far as I know. Sure, have all the heavyweight stuff in separate scripts that are just called, but platform specification/multiple platform builds/specifics of caching/secret handling/deployment handling are always different. Some tools (e.g. codecov) do abstract over some platforms, but not all, and the GitHub Actions model of "here is a literally pre-prepared step in your pipeline" can be pretty appealing. It's literally, pick your poison, and resign yourself to reimplementation if you ever need to switch platforms.
Arnavion 5y ago
If you have vendor lockin with GitHub Actions, it's because you chose to do it to yourself. Nothing prevents you from using only the `run` action to run a shell script so that everything that CI does can also be done on your dev machine. Both my personal projects and my $dayjob repositories have every test, etc triggered via `make test` or `test.sh`, then the GitHub Actions workflow YAML just `run`s it. Secrets also work fine - the makefile / shell script expects them to be defined as env vars, so the developer running them locally just needs to define those env vars regardless of how they obtained the secrets. https://news.ycombinator.com/item?id=25104253 https://news.ycombinator.com/item?id=25104253
- DogLover_ 5y ago
  Sure, but then I guess you always install the dependencies from scratch, can't utilize cache, and won't have a dependency graph as well. Parallelising your build/deployment will likely also be harder to do.
  - Arnavion 5y ago
    >Sure, but then I guess you always install the dependencies from scratch Sure? On your dev machines the dependencies are already installed. On GHA VMs the network is fast enough that installing deps is not slow. What's the problem? And if you really have a problem, presumably you have some master tarball / container image that your devs use to set up their dev machines because installing your deps is so complicated, so scp / pull that in your script? >can't utilize cache A cache is necessary for CI VMs that are cleaned for every run. When building locally your dev machine already has everything the cache would have. >and won't have a dependency graph as well. > >Parallelising your build/deployment will likely also be harder to do. You realize the two things shell scripts are good at is running commands either series or parallel, exactly how you want them? Instead of learning a brand new DSL to be able to do `if` and `&`, you just write `if` and `&`. This is already covered in the comment I linked.
    - DogLover_ 5y ago
      You make some good points and I tend to agree with your approach. What you have to do though is skip using "uses: actions/", "needs", and won't be able to use other actions that has been published to the Github marketplace. So you have to make a conscious decision to go against the way people usually uses Github actions and won't be able to utilize some of their features. You avoid vendor lock-in though, which is what we are talking about :)

greggman3 5y ago

You can run github actions offline https://github.com/nektos/act https://github.com/nektos/act I don't think github is trying to create lock-in, I think rather they were trying to make a way to easily share actions (not sure what other CIs systems are designed to have an ecosystem of publicly shared actions). The actions are public and therefore easy to make something that interprets them. I can only guess at some point there will be a push for CIs to converge on some "actions" standard, maybe?

tyingq 5y ago
That's neat, though it is a 3rd party trying to replicate it. Gitlab's open source runner supports parsing the ci yml and running a job locally, presumably using the same code as the platform, like: gitlab-runner exec docker some-job-name Though they would both suffer on any dependencies on platform hosted environment vars, secrets managers, etc.

misnome 5y ago

Are there any CI/CD metasystems that aren't vendor locked-in? GitHub/even GitLab, Jenkins (freestyle and scripted)/Azure/Travis.... all vendor-specific, as far as I know. Sure, have all the heavyweight stuff in separate scripts that are just called, but platform specification/multiple platform builds/specifics of caching/secret handling/deployment handling are always different. Some tools (e.g. codecov) do abstract over some platforms, but not all, and the GitHub Actions model of "here is a literally pre-prepared step in your pipeline" can be pretty appealing. It's literally, pick your poison, and resign yourself to reimplementation if you ever need to switch platforms.

Arnavion 5y ago

If you have vendor lockin with GitHub Actions, it's because you chose to do it to yourself. Nothing prevents you from using only the `run` action to run a shell script so that everything that CI does can also be done on your dev machine. Both my personal projects and my $dayjob repositories have every test, etc triggered via `make test` or `test.sh`, then the GitHub Actions workflow YAML just `run`s it. Secrets also work fine - the makefile / shell script expects them to be defined as env vars, so the developer running them locally just needs to define those env vars regardless of how they obtained the secrets. https://news.ycombinator.com/item?id=25104253 https://news.ycombinator.com/item?id=25104253

DogLover_ 5y ago
Sure, but then I guess you always install the dependencies from scratch, can't utilize cache, and won't have a dependency graph as well. Parallelising your build/deployment will likely also be harder to do.
- Arnavion 5y ago
  >Sure, but then I guess you always install the dependencies from scratch Sure? On your dev machines the dependencies are already installed. On GHA VMs the network is fast enough that installing deps is not slow. What's the problem? And if you really have a problem, presumably you have some master tarball / container image that your devs use to set up their dev machines because installing your deps is so complicated, so scp / pull that in your script? >can't utilize cache A cache is necessary for CI VMs that are cleaned for every run. When building locally your dev machine already has everything the cache would have. >and won't have a dependency graph as well. > >Parallelising your build/deployment will likely also be harder to do. You realize the two things shell scripts are good at is running commands either series or parallel, exactly how you want them? Instead of learning a brand new DSL to be able to do `if` and `&`, you just write `if` and `&`. This is already covered in the comment I linked.
  - DogLover_ 5y ago
    You make some good points and I tend to agree with your approach. What you have to do though is skip using "uses: actions/", "needs", and won't be able to use other actions that has been published to the Github marketplace. So you have to make a conscious decision to go against the way people usually uses Github actions and won't be able to utilize some of their features. You avoid vendor lock-in though, which is what we are talking about :)