Open BadIdeaException opened 9 months ago
After further investigation:
I have manually logged into the container that act had spun up, and indeed, running apt-cache show python3-semver
gives me same error. I then ran sudo apt update
and, lo and behold, the error disappears.
Indeed, inserting run: sudo apt update
as an extra step before cache-apt-pkgs-action makes the workflow work locally with act. I don't like having to insert extra steps for the sole purpose of making it play nice locally though.
At this point I felt like it might not be a bug with this action so much as a problem with act - they don't seem to have apt update
'd in the default image? But that doesn't make sense either, because I can apt install python3-semver
from the workflow. Without a previous apt update
, this shouldn't be possible either.
I'm a little confused now...
I would look at the package on install and then on update on the logs to see what the difference is. That would be a good start to the investigation. Post it here.
Hi and thanks for your response. Can you elaborate on what you mean by "on install" and "on update"?
Hi!
Had this issue while trying to use this action on a pipeline.
Turns out that the runner I was using (a self-hosted one) had no information about any almost any package, as consequence when the action tries to run a apt-cache --quiet=0 --no-all-versions show build-essential package-x package-y
(here).
Since @BadIdeaException has seen the problem while using act
I suspect the runner image used to simulate the GitHub runner suffers from the same problem.
Hi, we're observing the same issue with self-hosted runners. Our runners use the RunsOn AWS images which are based on the official GitHub Action images, so I'm not entirely sure what exactly is different. Running sudo apt-get update
before calling the cache-apt-pkgs-action fixes the issue, but it would be nice if the action handled this gracefully.
I haven't dug into the code but I assume the action does run apt-get update
anyway at some point, so maybe it's just a matter of reordering some steps to ensure apt-get update
runs before the call to apt-cache
that normalizes package names?
Not sure if that's simple.
I would expect not to run a apt update
if the packages I requested are already installed on the system.
I use nektos act to debug my workflows locally before committing them.
The following minimal reproducible example:
fails:
It looks like, at the heart of it, apt-cache is unable to find the requested packages, but I haven't been able to find an exact explanation for its exit codes.
It works when I actually run it on GitHub, just not locally.