refactor: CI only pulls each minikube once for each kubernetes version #2691
Conversation
| @@ -28,6 +28,8 @@ on: | |||
|
|
|||
| jobs: | |||
| integration_tests: | |||
| name: "Integration tests (${{ inputs.kube-version }}, ${{ inputs.java-version }}, ${{ inputs.it-category }}, | |||
There was a problem hiding this comment.
That is duplicated information which doesn't appear in the overview of the build outputs so we might as well remove it, imo
.github/workflows/build.yml
Outdated
| integration_tests: | ||
| name: "Integration tests (${{ inputs.kube-version }}, ${{ matrix.java }}, ${{ matrix.it-category }})" |
There was a problem hiding this comment.
Same here, as we never call this workflow directly, the kube version is redundant and leaving it out would make the rest stand out more, imo.
There was a problem hiding this comment.
if we don't specify the name it will be only "integration_tests" so I opted to repeat the info. I'm not sure what would be better solution. Still remove?
There was a problem hiding this comment.
So I'm not sure if it's better like this, but at least the information is not repeated.
Signed-off-by: xstefank <xstefank122@gmail.com>
xstefank
force-pushed
the
ci-refactor
branch
from
95ecb49 to
797caa1
Compare
|
I personally don't like it, because you don't see from the overview which job is which - |
Yeah, that's not great but it seems to be yet another level, not sure why it shows Experimental first either… |
|
@metacosm that's because we need to create matrix step by step and the each action/step has name. So before it was "integration_tests" a few times but we cannot skip the name in each step unless we would inline all actions into one file. Less readable but it would solve the naming issue and a few files that you need to go over when finding how it composes. @csviri WDYT? |
|
do we really want to test all the clients? It should be the responsibility of fabric8. and there were long time no issues with that. (Alhough I know there are now issues popping up with vertex). Maybe having just that removed from the matrix would sole the issue we facing. |
|
I get that this works, but feels that it brings quite a complexity. Only issue what we are facing is throttling. Having just fewer overall categies solves the problem, even if the tests run a bit long. If we have to choose between running the tests bit longer on CI vs complexity in the CI. I would probably choose longer runs tbh. |
|
What I would propose is also take a look how this would look like, if we would just remove the testing of various client flavors, and remove the integration test categories as a separate PR and maybe compare with this approach. (Can try later just quite sick atm) |
|
I would merge this and then figure out if we want to do something else. We need to address the quota issue first, imo. |
No description provided.