cachix/cachix-action

Best way to avoid hitting GitHub API limits?

shajra opened this issue · 3 comments

shajra commented

Hi, I'm using GitHub issues as a help desk. Let me know if there's a better place to ask questions.

I'm hitting the error below with an admittedly beefy workflow. You can see the workflow here. It gets through all the Linux jobs, waits through the delay (my first attempt at a fix), and then fails on the next job.

I think this isn't an issue of rate limiting as much as just making too many API calls in one workflow (which would explain to me why a delay isn't fixing my workflow).

Is there anything I can do to keep this work in one workflow? Would it help to merge some jobs together and get less parallelism? I'm soon to try that.

Also, I had a subscription to Cachix, but it lapsed due to some payment info changing. I just haven't gotten around to resubscribing. Would a paid account have better limits with respect to GitHub?

If there is something to come out of this ticket, maybe it would be some additions to the documentation addressing recommendations for dealing with GitHub limits. I saw some of that with the Nix installer action.

Thanks for your help.

/bin/bash -c nix-env --quiet -j8 -iA cachix -f https://cachix.org/api/v1/install
  disabling binary cache 'http://127.0.0.1:37515/' for 60 seconds
  error: unable to download 'http://[12](https://github.com/shajra/shajra-provisioning/actions/runs/7835296323/job/21383936842#step:5:13)7.0.0.1:37515/nar/1x450sbwg0qwvlzk5rhr66gdj51qyaq2y8rlwavzvm3kckca57a6.nar.xz': HTTP error 418
  
         response body:
  
         GitHub API error: API error (429 Too Many Requests): StructuredApiError { message: "Request was blocked due to exceeding usage of resource 'Count' in namespace ''." }
  error:
         … while calling the 'storePath' builtin
  
           at /nix/store/69yavjm33h70w36gfim3fk0waribapas-source:19:27:
  
             [18](https://github.com/shajra/shajra-provisioning/actions/runs/7835296323/job/21383936842#step:5:19)|                 inherit outputName;
             [19](https://github.com/shajra/shajra-provisioning/actions/runs/7835296323/job/21383936842#step:5:20)|                 outPath = builtins.storePath (builtins.getAttr outputName outputs);
               |                           ^
             [20](https://github.com/shajra/shajra-provisioning/actions/runs/7835296323/job/21383936842#step:5:21)|                 # TODO: we lie here so that Nix won't build it
  
         error: path '/nix/store/zwq52wxx829didbi42j69mh91h3sxfxw-cachix-1.7' does not exist and cannot be created
  Error: Action failed with error: Error: The process '/bin/bash' failed with exit code 1
domenkozar commented

This seems to be an error with nix-magic-cache :)

sandydoo commented

To clarify a bit, this isn't an issue with this action. You need to create a GitHub API token and set up Nix to use it. That substantially increases your API limits. Some Nix installers offer a way to do this for you.

shajra commented

Thanks for the clarification. I have it all fixed now. I don't know if the problem is really with nix-magic-cache as @domenkozar commented above. I think it was because I switched (for no reason other than to try it out) to the Determinant Systems Nix installer. And it doesn't seem to set the GitHub token a way I find intuitive. I just stopped poking at it and went back to the Cachix Nix installer action. That seems to be all I need.

Also, both the Cachix action and the Magic Nix Cache seem to be working fine together. I actually had this all working a long time ago, and then something broke. I think I blamed my usage, rather than thinking that maybe it was a problem with the Determinant Systems Nix installer. My hunch is that they used to set the token the way I would expect, and then they stopped. Also, I probably got what I deserved for using their @main version. Nondeterminant Systems when you do it that way.