| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com> |
| Subject: | Re: ci: CCache churns through available space too quickly |
| Date: | 2026-06-18 04:50:42 |
| Message-ID: | CA+hUKG+jQxsyaHqJEWFU8aAD5+aC6fEaKuWqd=U=Xc-4T4gOMg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jun 6, 2026 at 8:09 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> With cirrus-ci all branches shared one cache, but that's not the case with
> github actions. Except for being able to read caches from the default branch
> (master in our case), other branches have completely separate cache
> namespaces. That's probably the right call, safety wise, but makes our ccache
> approach .. not great.
For the record: based on what Andres explained about how GHA cache
sharing works, I taught cfbot to mirror the master branch in its
postgresql-cfbot/postgresql account, and use the latest successful CI
run from there to select the base commit for the cf/XXX branches it
maintains. IIUC that should work well for this cache sharing policy,
since master's cache should be uploaded and ready to reuse at that
point. Perhaps we'll also get some data on how successful these new
heuristics are?
https://github.com/postgresql-cfbot/postgresql/commits/master/
I also taught cfbot to delete old cf/XXX branches with no builds in
over 90 days (we went from over 9000 to 376...). That matches
Github's own retention period for logs, artefacts etc, so stale
branches are not very interesting and it seemed like a good idea not
to waste resources or clutter the UI with junk.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zsolt Parragi | 2026-06-18 04:54:59 | Re: Require SSL connection to postgres for oauth |
| Previous Message | Michael Paquier | 2026-06-18 04:37:34 | Re: Unexpected behavior after OOM errors |