<https://github.com/LegalizeAdulthood/vcpkg-github-cache>

For a long time I've struggled with vcpkg binary caching on my github
CI jobs. There's a variety of critical information buried deep across
various documentation pages that all interact when you attempt to use
binary caching on a github repository with public github runners and
CI workflows. This weekend I finally got it all figured out and
debugged for my public repositories and realized that the steps needed
to make everything work are non-obvious and intricate. This is the
perfect thing for packaging up as a github workflow action for reuse
across repositories.

This project consists of two actions:
- one that does all the setup
- one that analyzes your build log

This gives you details on how your build interacted with vcpkg binary
caching to report problems. Usually the build summary is all you need
to understand the cache: cold seed, warm hit, partial hit, etc. Should
you need to dig in deeper to debug a weird situation there are two
knobs -- debug and trace -- that can give you enough detail on
everything that happened so you can sort out problems without having
to manually add logging to your workflow.

It may still be necessary to manually adjust the permissions on
individual packages that are shared across repositories on your
account. Unfortunately there's no way to manipulate the permissions programmatically. The analyze action smooths this out by giving you a
table of packages that had permission issues, with links to each
package's permission page on github. From there you can quickly adjust permissions as needed without having to hunt through a long list of
packages on your account.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/14/2026 7:33 AM, Richard wrote:

<https://github.com/LegalizeAdulthood/vcpkg-github-cache>

For a long time I've struggled with vcpkg binary caching on my github
CI jobs. There's a variety of critical information buried deep across various documentation pages that all interact when you attempt to use
binary caching on a github repository with public github runners and
CI workflows. This weekend I finally got it all figured out and
debugged for my public repositories and realized that the steps needed
to make everything work are non-obvious and intricate. This is the
perfect thing for packaging up as a github workflow action for reuse
across repositories.

This project consists of two actions:
- one that does all the setup
- one that analyzes your build log

This gives you details on how your build interacted with vcpkg binary
caching to report problems. Usually the build summary is all you need
to understand the cache: cold seed, warm hit, partial hit, etc. Should
you need to dig in deeper to debug a weird situation there are two
knobs -- debug and trace -- that can give you enough detail on
everything that happened so you can sort out problems without having
to manually add logging to your workflow.

It may still be necessary to manually adjust the permissions on
individual packages that are shared across repositories on your
account. Unfortunately there's no way to manipulate the permissions programmatically. The analyze action smooths this out by giving you a
table of packages that had permission issues, with links to each
package's permission page on github. From there you can quickly adjust permissions as needed without having to hunt through a long list of
packages on your account.

Interesting. thanks. Fwiw, did you ever update your book for dx12?

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> spake the secret code <110n41v$3t32p$1@dont-email.me> thusly:

Interesting. thanks. Fwiw, did you ever update your book for dx12?

I never even finished updating it for D3D9 :).

LLMs fill the gap now, I'm not sure what updating the book would do at
this point.

When I started writing that book, there was only one book on D3D and
it covered D3D7 and the book sucked. The "famous last words" were: "I
could write a book better than that!" And I did, for the most part.
My best contribution was the pipeline poster.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Terminals Wiki <http://terminals-wiki.org>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 6/14/2026 5:48 PM, Richard wrote:

"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> spake the secret code <110n41v$3t32p$1@dont-email.me> thusly:

Interesting. thanks. Fwiw, did you ever update your book for dx12?

I never even finished updating it for D3D9 :).

LLMs fill the gap now, I'm not sure what updating the book would do at
this point.

When I started writing that book, there was only one book on D3D and
it covered D3D7 and the book sucked. The "famous last words" were: "I
could write a book better than that!" And I did, for the most part.
My best contribution was the pipeline poster.

Fwiw, I finally taught myself enough dx12 to get things to a point where
a single memcpy updates all of my state per frame. Pretty nice and
better than modern opengl.

--- PyGate Linux v1.5.16
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)