I was trying to implement some new feature in some larger somewhat messy project (RETURNN but not so relevant).
So I created a new branch, also ma...
For further actions, you may consider blocking this person and/or reporting abuse
Hm, there was some post here, but now it's gone, while I was already answering. Here my answer:
We already do trunk-based development. And also we have lots of CI tests. And exactly of this, I was not merging it in before because still some tests were failing. In the end after everything was fixed, it turned out to be a huge number of commits. And this is the situation now. I.e. I want to split this up.
Usually this does not happen like this, and changes turn out to be smaller. But because we require that tests are always passing, one particular change, fix, or extension needs follow-up fixes of other things.
Do you have some automatics test that's taking long times ?
There are about 50 GitHub CI jobs, each running a lot of different tests. The longest job takes about 10 minutes but most take only 1-3 minutes. But overall until GitHub runs through all of them, it takes maybe 12 minutes or so, once it started, because many run in parallel.
These are run on every push and for every PR. When I keep updating the PR, this can queue a lot of CI runs. And then sometimes I need to wait hours until I see the CI results.
This is a big problem. Because we must know that the tests are passing before we merge something in. So I'm often just waiting.
And could-you rewrite thoses test using Test double to make them quicker ?
I think most tests on their own are already pretty small (most probably take about 0.1 sec or so). I don't think you can optimize much there.
This longer 10 minute test runs PyCharm CLI checks on code style. I haven't really found ways to speed it up.
Maybe with a lot of effort, you could somehow reduce it a bit. But even if you maybe reduce it by half (unrealistic), this problem would still persists, that you often need to wait (although of course to a lesser degree).
I think we are still doing fine with about 10 minutes per CI run. From what I have heard from Google and elsewhere, it can take much longer. And they also manage to still stay productive. So maybe they don't need to reiterate too often for one set of changes, or they don't wait each time for the tests to pass. But this is only because I now want to split it up and actually figure out working independent sets of commits (working = passing tests).
Do you run thoses fast test on your own machine before commit them (before CI) ?