D4no0

D4no0

Imagine the case where you have a project where you added 200 source files, but you never changed a dependency, this is a very common case for more mature projects where adding/updating dependencies is not something you do often.

Using the cache strategy that relies on ${{ hashFiles('**/mix.lock') }}, you will have to compile/generate artifacts for all those source files at every pipeline run, and taking in considerations there are usually at least 4-5 of them for each commit, the penalty for old cache will cost you a lot of time.

0
Post #11
paulanthonywilson

paulanthonywilson OP

I’ve not got to the bottom of the “Old PLT file” issue, and have not seen it again (yet) in our pipelines.

I’m not clear on the cache invalidation for PLT files suggestion on the runner-id here, but then again I’m not currently using Github Actions. My experience is that that the big time-sink when building the PLTs is in the initial run and there’s not a lot happens to the PLTs even after lots of source file changes.

Caching PLTs based on mix.lock works fine in my experience. (Except when it doesn’t - see above).

¯\(°_o)/¯:hot_beverage:

0
Post #12
D4no0

D4no0

If you are paying for the service, which a lot of companies that depend on github do, a difference between a pipeline running 2 minutes and 4 minutes becomes a valid concern.

1
Post #13
BartOtten

BartOtten

Does this help?

Need to fix the CI of Routex too as since I added Dialyzer it runs a few minutes instead of seconds.

0
Post #14
dimitarvp

dimitarvp

I wonder if we can ultimately just standardize this and refer to it via an identifier (think GHA allows this but since I always avoided it like the plague, I wouldn’t know for sure).

0
Post #15
D4no0

D4no0

You could make a action that does that, however in order to make it flexible you need a lot of parameters, which ultimately makes it less readable compared to copy-pasting the original steps.

I also might be paranoid but I think that ultimately the notion of immutable cache is here in the detrement of the end-user and its obscurity and complexity only amounts to pipelines running for longer time, so the billing can be higher. Ultimately the virtual value immutable cache brings, AKA the cache that can be served from CDNs is useless, ideally the cache should be local to the machine that runs the jobs so it’s fast to restore.

I always laughed when it took almost 30 seconds to restore cache in CircleCI, what is the point of having it if you can compile the project from scratch faster?

1
Post #16
dimitarvp

dimitarvp

Could be, I would not know, admittedly I always stayed away. But to me it seems there should not be too many knobs to turn: have or not have Dialyzer is actually the only one I can think of right now. :thinking:

But it wouldn’t hurt if we had a few strongly opinionated actions, right?

Yeah, same, I watched live output of the actions on production deployment days and was confused but then realized that most of these workers have network-mounted disks which of course defeats like 80% of the whole thing…

0
Post #17
D4no0

D4no0

I think the effort would be better spent on making a mutable local-first cache system, otherwise all of these solutions are just a hack around the main problem.

If only these goddamn action weren’t written in JS… also BTW you cannot write tests for them, amazing.

0
Post #18
dimitarvp

dimitarvp

That’s not happening because again, the virtual instances where the actions are ran are often using network-mounted disks. They don’t even have local disks. :roll_eyes:

0
Post #19
RobertoSchneiders

RobertoSchneiders

Understood. We update dependencies with Dependabot every week, so that’s not a big issue for us but I will keep an eye on it, thank you.

0
Post #20