> that adds around 5 minute to every PR I receive...
I am sure not every PR you get touches files under '.github/workflows'. Are you sure you were replying to me and not @_fat_santa? It's his approach that ruins CI/CD as far as tests are concerned.
> Sure, maybe it's not as convenient as replacing the yml file, but I could embed a script in the tests that will just mine as long as possible.
Yes, but that slows things down a lot. Now you need to write a fake unit test that spawns a process and that will require to clone a project, get a project to build, writing different code for different programming languages and unit test frameworks...
I am sure not every PR you get touches files under '.github/workflows'. Are you sure you were replying to me and not @_fat_santa? It's his approach that ruins CI/CD as far as tests are concerned.
> Sure, maybe it's not as convenient as replacing the yml file, but I could embed a script in the tests that will just mine as long as possible.
Yes, but that slows things down a lot. Now you need to write a fake unit test that spawns a process and that will require to clone a project, get a project to build, writing different code for different programming languages and unit test frameworks...
Also, you would not be able to defeat my runtime timeouts (just added to https://github.com/eclipse/lyo/blob/master/.github/workflows... after reading this post) if GH tarpits CI execution with manual approvals if you touch that config in your PR.