Hi,

this PR closes #20760 as discussed. To fix this I needed to fix some related quirks around fetching already existing issues:

  • The GitHub /pulls API is not having feature-parity with the /issues API when it comes to filtering and caused the API to return quite a lot of issues (e.g. all open ones instead of just open ones by the specific creator). I switched to the /issues API again + a corresponding jq selection filter for the pull_request key.
  • Apparently there are some control characters in the response that cause the intermediate echo to fail on my local machine. I think I haven't noticed this before because it seems to be related to the milestone description (I'm guessing newlines) that wasn't assigned previously all the time. Inlining the curl and jq commands fixes this. Or at least makes it more stable.

Cheers, Christoph

Comment From: mbhave

Thanks @dreis2211. From the change it looks like we could have two PRs open at the same time? For example, if there is an outstanding PR titled Upgrade CI to Docker 19.03.8 and the pipeline detects another docker version, it would create a PR titled Upgrade CI to Docker 19.03.9. Since the ci-docker-image branch is shared between the PRs, it would make the first PR invalid and there's no obvious way to indicate what invalidated that PR. I'm not sure what it should do in such a scenario.

Comment From: dreis2211

As the job only runs once per week that seems unlikely, but it's possible. It seems unlikely enough that you could simply manually close the older one in favor of the new one, if that really happens.

Apart from that, I could think of introducing a matching that doesn't do a full match against the title but only if the title starts with Upgrade CI to Docker. Simply let me know if I should add that.

Comment From: mbhave

Yeah, it does seem unlikely and closing the old PR manually doesn't seem so bad. The case that I'm more concerned about is if the latest-version is a pre-release. We won't find an existing issue with that title, let's say Upgrade CI to Docker 19.03.9-rc. We then force push master to the ci-docker-master branch, potentially affecting an open PR titled Upgrade CI to Docker 19.03.8. Given that possibility, I think it might be better to look for an issue title that starts with Upgrade CI to Docker like you said.

Comment From: dreis2211

Pre-release versions are anyhow skipped already:

if [[ $latest_version =~ (beta|rc) ]]; then
    echo "Skip pre-release versions"
    exit 0;
fi

Comment From: mbhave

Yeah, but the put to the ci-docker-branch happens no matter what the detect-docker-updates.sh does. That's the reason we do this so that if there is an existing PR, the branch remains unchanged.

Comment From: dreis2211

Right. In that case give me a couple of minutes to implement the new title matching...

Comment From: dreis2211

Pushed

Comment From: mbhave

Thansk again, @dreis2211.