Clean / Reproducible Builds

Questions / Help
, , , ,
1

This week I upgraded from Phoenix 1.3 to 1.4.

Everything was compiling well on my machine afterwards.

This is the script I use to run a dev server

mix local.rebar --force;
mix local.hex --force;
mix clean;
mix deps.get --all;
mix compile;
iex --name api@127.0.0.1 -S mix phx.server;

I have a similar script which runs tests locally.

But after doing mix deps.clean --all and trying to recompile, I had a problem.

I have a custom Ecto type dependency -> https://github.com/OvermindDL1/ecto_interval Which seems to have dependency problems. I have to figure that out.

(Turns out, just needed to update it to the latest version)

But my question is, what do you do to ensure your builds are reproducible and you catch problems like this?

I am sure I am committing a common mistake, perhaps it would be a good idea to somehow simplify the required mix commands…

2

For Continuous Integration (test, formatter, Credo) and deployment we’re using Dockerized versions of our apps. Looks pretty much the same as your script: we set MIX_ENV and there’s no need for mix clean. For local development, we use the regular flow.

1 Like
3

Yeh, I assumed it would suffice.

But somehow, after updating, I didn’t see the ecto_interval issue until Jenkins and then I reproduced it with mix deps.clean --all.

Perhaps I hit an edge case. Or probably, I do not understand mix deps etc. well enough…

4

Can you check to what versions did you deps resolve? Maybe they were not properly pinned?

1 Like
5

Well, one issue was the library depended on ecto 1 or ecto 2 versions.

And the updated version of the library added ecto 3.

So I upgraded and everything was fine…

The problem was, I didn’t see this with my usual build script (see above) which bothers me…

1 Like
6

In my experience with Docker, it is convenient to add the “deps” and “_build” folders to the .dockerignore file so that they are not mapped into the environment in which the image is built (forcing a recompile while the image is being constructed).

2 Likes
7

Wait what? What dependency problem? I’ve been using it without issues to date? o.O

1 Like
8

Your package is great. Just somehow I managed to update to Ecto 3, without any complaints from mix, to warn me to update ecto_interval also… Slightly disconcerting.

9

I also used docker, but had to migrate away due to complex interop with other services, and docker config issue.

From your docker experience, it seems more or less analogous to adding a mix deps.clean --all which makes builds slow, but perhaps that’s the only way to be 100% sure…

10

It is slower. I am also trying to make sure that all my dependencies are compiled in the architecture of the docker container, rather than having some of them that might have been built on my docker host machine. This would be particularly important if any of the dependencies included native code.