Upgrade to ubuntu:bionic-20200311
Comment From: dreis2211
I wonder why there was a second issue created. As I can't take a look at the logs of https://ci.spring.io/teams/spring-boot/pipelines/spring-boot-2.3.x/jobs/detect-ubuntu-image-updates/builds/5 I can't tell why.
Comment From: snicoll
Believe it or not, I can't either (on that particular build)
Comment From: snicoll
With the help of @mbhave and @wilkinsona, the reason why I can't expand that particular build is because it didn't log anything.
Comment From: snicoll
race condition?
Comment From: dreis2211
Well, it still needs to be executed twice somehow to create two tasks that could race against each other. Anyhow, the logic is the same as in the JDK updates so it theoretically suffers from the same problem. Should we close this one and open a new issue to investigate?
Comment From: wilkinsona
Yep. It's a distributed race condition. The check ran in the 2.1.x, 2.2.x, and 2.3.x pipelines. 2.1.x was a bit slow and detected that the issue already existed. 2.2.x and 2.3.x both checked in parallel, didn't find an existing issue, and then both created one.
Comment From: dreis2211
Ah, between the different branches. Of course. Should we shuffle the timings a bit in the pipeline.yml throughout the various branches?
Comment From: wilkinsona
I'm not sure if we should do that, or check for and create branch-specific issues.
Comment From: mbhave
I think we should create branch specific issues and assign the milestone at the time of issue creation.
Comment From: dreis2211
It might be a bit difficult to assign 2.2.6 or 2.3.0.M4. 2.2.x or 2.3.x should be relatively simple, though. Which means someone needs to assign the specific milestone manually later, I guess (in order to be reflected in the release notes). What do you think?
Comment From: mbhave
That's consistent with other issues where we manually change the milestone for closed issues from the .x version to the specific version.
Comment From: dreis2211
Mind if I open a new issue to track these efforts?
Comment From: mbhave
Actually, I'm having second thoughts about this. If we create the same issue in multiple milestones we need to remember to not create the forward-port issue when forward-merging. Instead the forward-merge needs to close the issue that has already been created by the automation. I don't think it's a big deal but it does break the workflow a bit.
Comment From: mbhave
I'll close this one in favor of #20680 in any case. @dreis2211 let's continue the discussion on that one.