Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CI: Caching #41

Closed
niklasdewally opened this issue Nov 4, 2023 · 4 comments
Closed

CI: Caching #41

niklasdewally opened this issue Nov 4, 2023 · 4 comments
Labels
area::ci Related to CI, coverage, Github, etc.

Comments

@niklasdewally
Copy link
Contributor

niklasdewally commented Nov 4, 2023

Continue work done on #36, #37.

In short: we want to create a sensible caching scheme that allows all crates in this project to be cached, and updated as appropriate so that PRs do not need to clean build things. Some actions only use one crate, some use two, some use them all, so the caching needs to be invariant to this.

There were a few problems and approaches to these discussed in #36 #37.

@niklasdewally
Copy link
Contributor Author

In particular, look at how conjure itself does it - it does
foo-hash-bar-hash-timestamp.

That way, you never need to delete then resave the cache as I do, you just make one with a newer timestamp and let github GC them all.

@niklasdewally niklasdewally added the area::ci Related to CI, coverage, Github, etc. label Nov 15, 2023
@ozgurakgun
Copy link
Contributor

Caching isn't quite satisfactory at the moment, not entirely sure why.

PR #99 just failed to find a cache even though I just made small incremental changes.

See https://github.com/conjure-cp/conjure-oxide/actions/runs/6950773148/job/18911526725?pr=99

Cache not found for input keys: stable-Linux-gitmodules-e3b0c44298fc1c149afbf4c8996fb92427ae41e4-cargo-5ca8ee75eb05edfb53dc573ace4fa8a32bdee41b49119576a8e7952a62cabdda, stable-Linux-gitmodules-

I suggest (unless people see a reason not to do this)

  • We do the timestamp based thing the previous comment alludes to
  • We remove the full cache action, not sure if this is helping
  • We could also introduce ccache, there is an action for it I use in conjure, in addition to caching cargo dirs

@niklasdewally
Copy link
Contributor Author

Caching isn't quite satisfactory at the moment, not entirely sure why.

PR #99 just failed to find a cache even though I just made small incremental changes.

See https://github.com/conjure-cp/conjure-oxide/actions/runs/6950773148/job/18911526725?pr=99

Cache not found for input keys: stable-Linux-gitmodules-e3b0c44298fc1c149afbf4c8996fb92427ae41e4-cargo-5ca8ee75eb05edfb53dc573ace4fa8a32bdee41b49119576a8e7952a62cabdda, stable-Linux-gitmodules-

I suggest (unless people see a reason not to do this)

  • We do the timestamp based thing the previous comment alludes to
  • We remove the full cache action, not sure if this is helping
  • We could also introduce ccache, there is an action for it I use in conjure, in addition to caching cargo dirs

I came across this before and was suspecting an emdash or something in the GitHub cache match somewhere - there's no reason why it shouldn't match as it currently is. Changing it entirely will be easier than debugging this I imagine

ozgurakgun added a commit to ozgurakgun/conjure-oxide that referenced this issue Nov 22, 2023
@niklasdewally
Copy link
Contributor Author

@ozgurakgun seems to be fixed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area::ci Related to CI, coverage, Github, etc.
Projects
None yet
Development

No branches or pull requests

2 participants