various pipeline improvements #1454
Conversation
| @@ -86,6 +86,7 @@ | |||
| <plugin> | |||
| <groupId>org.apache.maven.plugins</groupId> | |||
| <artifactId>maven-failsafe-plugin</artifactId> | |||
| <version>3.1.2</version> | |||
There was a problem hiding this comment.
there is an interesting pattern that I have observed with all builds that have timed out recently for a few days and we kept re-triggering. All of them where hanging in one of the phases of maven-failsafe-plugin plugin, and this is why our builds were failing. It was hanging for even 20 minutes at times. Why? and why now? No idea, I can't even trigger a thread dump to understand what is going on, neither can I replicate this locally.
Instead what I found is a few mentions about this on the web, and everyone seemed to magically get away from the problem by upgrading. So I did the same here. What I have observed across this successful builds is that the "hang" is not there anymore, but we could simply be lucky here.
Either way, upgrading would not hurt at all, imo.
There was a problem hiding this comment.
I assume the plugin version is maintained by boot? What version are we currently using? Is the version different in main? If we change the version, can we change in the the k8s parent pom in the dependency management section so we are not changing it everywhere?
There was a problem hiding this comment.
-
- yes, it is maintained by boot
-
2.22.2is what we are currently using
-
mainbranch uses the same2.22.2
-
- excellent point about the
pluginManagement, will fix this one.
- excellent point about the
There was a problem hiding this comment.
I am still uneasy about this change. Making a change to a plugin version purely due to the build system feels wrong to me...its going to put more burden on us to keep it up to date and also we are diverging from the spring dependency management.
The best solution I could think of that might work is to override the version specifically when we are building on github actions only. At least it isolates it.
There was a problem hiding this comment.
done, thank you for the feedback
| @@ -61,7 +61,7 @@ runs: | |||
| ./mvnw -s .settings.xml \ | |||
| -DtestsToRun=${TEST_ARG[@]} \ | |||
| -e clean install \ | |||
| -U -P sonar -nsu --batch-mode \ | |||
There was a problem hiding this comment.
it was weird looking here: both -U and -nsu which is the opposite of -U.
In general, our .m2 is as fresh as it can get at this point, so there is no need for -U, we have already updated snapshots before this
| @@ -3,10 +3,11 @@ description: clean space | |||
| runs: | |||
| using: "composite" | |||
| steps: | |||
| - name: apt-update | |||
| - name: gcloud | |||
There was a problem hiding this comment.
I was going nuts with github actions in this step. It was failing the whole day for me in these sequence of events:
- "what is the version of gcloud?" 477.0.0
- "delete gcloud" - it's not present.
How can it be not present if you just gave me the version above? :) May be github was upgrading something in the background and I was caught in the middle, I don't know.
I am leaving a small print statement for gcloud version for a few weeks and will monitor this one across builds and eventually get rid of it. It's just an informative statement, does nothing else.
| @@ -29,9 +29,6 @@ jobs: | |||
| - name: checkout project | |||
| uses: actions/checkout@v2 | |||
|
|
|||
| - name: clean space | |||
There was a problem hiding this comment.
we don't need this one here, we do need to clean space, but not here, there is no pressure on this stage. A 5 minutes improvement on the overall build time :)
|
@ryanjbaxter ready to be looked at, left comments everywhere. thank you |
| - name: apt-update | ||
|
|
||
| ### this is supposed to be simpler, but it's a work-around for: | ||
| ### https://github.com/jlumbroso/free-disk-space/issues/14 |
There was a problem hiding this comment.
so some users started reporting the same issue that I am seeing, that simply using jlumbroso/free-disk-space@main fails in most recent builds. It fails saying that gcloud is not present and can not be removed. I assume github started packaging this artifact in a different manner, not via apt, so this breaks the plugin we were using.
Until there is a real fix for this, this is a work-around. Basically in plain english it says: remove everything that we were removing via large-packages: true, except gcloud. This one is removed a bit differently"
|
Is there a reason why you marked this as a draft again? |
|
yes, there is a PR where I merged this one and it still fails, I want to see why. Will ping you as soon as I figure out what is going on. btw, |
|
@ryanjbaxter actually no, we can merge this one and I can investigate what is going on there and potentially have another fix. |
No description provided.