Dialyzer error: Old PLT file

[RobertoSchneiders]

@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.

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.

[alexslade]

@RobertoSchneiders We recently fixed this issue too.

Perhaps you have the same cause: are you not pinning the patch version of erlang in your CI?

Here is the cause breakdown from our bug ticket:

• Dialyzer creates an md5 hash of files to check, and that includes beam files.
• We are not pinning an exact version of erlang in CI
• Prior to each failing PLT check has been an erlang patch version bump!
• It looks like erlang project releases the patch bumps roughly weekly. This explains the roughly-weekly occurences we were seeing. It wasn’t a timestamp issues as first suspected.
• This patch bump means that the PLT files are different to the ones in the cache, so dialyzer is correctly flagging the old PLT files.

Proposed solution: check .tool-versions during CI setup and install the exact pinned version of erlang that our project uses.

Note: I also included the erlang version in the cache key, to avoid confusion in future and to immediately bust the cache lookup.

[lud]

Hey! I just updated my Github config

I use this strategy on my personal projects: nvir/.github/workflows/elixir.yaml at main · lud/nvir · GitHub

It’s based on the well-known template but I removed the check on cache hit for the PLT, as I got problems with that. And it’s simpler. Also checking the PLT is actually fast, even for large projects.

If you add 200 files I’m not sure how slow it is but that’s why I added a cache_vsn variable that I can bump. But I too use dependabot so the mix.lock file is updated quite often.

I wonder if in addition to hashFiles it is possible to use something like find lib test -type f | wc -l in the cache keys, that would make dialyzer update when files are added. But at some point you will never use the cache if you invalidate it for everychange.

So I prefer the current strategy of hashing mix.lock and just regenerate the PLT for the app code only. Also I feel like Github action got really faster lately.

[RobertoSchneiders]

awesome! You were right, we were not pinning the patch version in CI. I followed your suggestions.

Thank you!

[dimitarvp]

All of this thread really makes me want somebody open-sources an exact and very detailed CI/CD setup(s) for Elixir projects that work perfectly on GitHub, GitLab, BitBucket, any Forgejo hosting etc.

It seems to annoying to do every time.

[paulanthonywilson]

@dimitarvp

All of this thread really makes me want somebody open-sources an exact and very detailed CI/CD setup(s)

yeah, someone should do that . Stares pointedly

Wouldn’t help the OP (me) who is in the unfortunate situation of building on Azure.

[dimitarvp]

Hey, at least for the moment I have an excuse: I’m deep into the job search swamp.

Later on, why not. It’s one of those things that should have been nailed and written in stone like 5 years ago.

[paulanthonywilson]

@dimitarvp

Hey, at least for the moment I have an excuse: I’m deep into the job search swamp.

Sorry, I was kidding. Good look with wading through the job swamp!

We were also not pinning the exact erlang version and seem to have just hit the issue again when an updated image was used from Docker. It’s good to have an explanation.