Cache Swift Evolution JSON file locally on disk

[ole]

Currently, we download the JSON file on every invocation of the workflow, which is really wasteful and slow.

[dempseyatgithub]

You may already be thinking along these lines but if you use the GitHub API endpoint at: https://api.github.com/repos/apple/swift-evolution/branches/main

It will return the commit of the main branch. You can check it against the commit value in the cached evolution.json file and only download a new version if they do not match.

The GitHub API docs are here: https://docs.github.com/en/rest/branches/branches?apiVersion=2022-11-28#get-a-branch

And something like this should work for decoding the result (excluding a lot of additional branch information) from the API:

struct GHBranch: Codable {
    let name: String
    let commit: Commit
    struct Commit: Codable {
        let sha: String
    }
}

[ole]

@dempseyatgithub That's a good idea, thanks!

[ole]

I've been running a few informal tests over the past few days to check the HTTP caching behavior of the server download.switf.org that hosts the evolution.json file. It looks like the server correctly reports via the HTTP response headers whether the file has changed. Example:

$ curl --head "https://download.swift.org/swift-evolution/v1/evolution.json"
HTTP/1.1 200 OK
…
ETag: "D876AE18FBE60E698072F81210C48EBB"
Cache-Control: max-age=3600, public
Last-Modified: Wed, 22 May 2024 13:38:28 GMT
…

Specifically, it looks like we can perform a HEAD request and rely on the ETag field to determine whether we need to redownload the full file.

This strikes me as the better approach than asking a different source of truth (the GitHub API). It means we have to store the HTTP response headers separately, but that's not a big deal.

[dempseyatgithub]

Thanks for doing that investigation @ole. That seems better than what I had suggested, I will remember this technique for my own projects.