3 ms·
Other people must have very different setups to warrant this kind of additional overhead and tooling. In our repo local testing is first. You check out the cod
by iandanforth 3y ago
Other people must have very different setups to warrant this kind of additional overhead and tooling.
In our repo local testing is first. You check out the code and can run the tests. The github runners do the same steps the readme encourages humans to do when running tests locally.
Also I'm not sure what duplication the author is avoiding with their DSL as Github actions can be broken into components and reused and parameterized. Of course if you don't like YAML you're never going to be happy until you've wrapped it in your own layer of tech debt.
- WirelessGigabit 3y agoThis is my approach too. I don't use any of all-in-one actions. I write the things that I need to have locally, in bash, or a build.rs script or via package.json. Then I invoke those things in GitHub actions. I split them up so they can run concurrently.
- benrutter 3y agoThe times I've seen more complex testing set-ups that use actions is normally some combination of: 1. Testing involves some kind of complex environment 2. IT infrastructure in some corporations makes setting up that environment impossible. I worked once in a role where I had to write a library aimed for working with spark, but getting spark (i.e. java etc) installed on my machine involved weeks worth of requests and escalations to IT. A lot of libraries (I'm thinking of adlfs as a good example which interacts with azure data lake file systrmd) have to have relatively complex testing involving docker by nature of what they are. None if those points make "put in a PR to run tests" a good or justifiable workflow. But I understand how people wind up falling into that trap.