search

dotnet / docker-tools

This is a repo to house some common tools for our various docker repos.
MIT License
124 stars 46 forks source link

EOL annotations are being applied to the newly supported images #1433

Closed mthalman closed 2 months ago

mthalman commented 2 months ago

After enabling EOL annotations in the dotnet-docker nightly branch, it was found that EOL annotations get applied to the images that are being newly published in that run. This happens because we're not getting the newly updated version of the image-info JSON file which defines what the currently supported images are. We're actually using the previous version of that file, which doesn't include the newly published images. So everything not in that file is considered to be EOL. Thus, the new images get EOL annotations applied to them.

The reason we're using the old version of the image info file is because the publish logic indicated below is not operating as expected:

https://github.com/dotnet/docker-tools/blob/597eb0f9628a77924f63c1e2683bf5f8cf314317/eng/common/templates/jobs/publish.yml#L109-L128

The intent is to do the following:

  1. Download the current (old) version of the image info file from GitHub.
  2. Run the Image Builder command which updates that file in GitHub.
  3. Download the current (new) version of the image info file from GitHub.

The issue is that step 3 is still getting the old version of the file. I believe this is just a timing issue where use of the raw.githubusercontent.com URL is not retrieving the latest state of the file at the point we retrieve it. The commit has been made in the repo but raw.githubusercontent.com is not reflecting that state yet.

dotnet-issue-labeler[bot] commented 2 months ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

dotnet-issue-labeler[bot] commented 2 months ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

mthalman commented 2 months ago

This could actually be caused by the GitHub server returning a cached version of the file. I will experiment to see if using a Cache-Control header on the request can avoid that.

mthalman commented 2 months ago

Ok, there is significant latency with respect to raw.githubusercontent.com reflecting the latest content of the repo. I made a commit in a repo and then accessed that file via raw.githubusercontent.com, and it took several minutes for my change to show up there (even when using Cache-Control). This means raw.githubusercontent.com should not be used to download content for our pipeline as it does not reliably provide the latest content.