docker: fix dart-sass arch mismatch, /cache permissions

[dvdksn]

• Closes Check cache dir creation permissions vs Docker image #12956
• Closes Dockerfile Dart Sass permission issue on MacOS #12957

The dart-sass setup used the $BUILDARCH variable to fetch the dart-sass
binary, which resulted in the wrong architecture being downloaded when building
for another architecture. The first commit changes it to use $TARGETARCH
instead. It also simplifies/inlines the dart-sass setup.

The second commit fixes the permission issue with /cache being owned by root.

[dvdksn]

@bep can you try building a dart-sass project with this version? I pushed an image of this build to davidkarlsson416/hugo:12959

docker run -v .:/project davidkarlsson416/hugo:12959 build

[bep]

docker run -v .:/project davidkarlsson416/hugo:12959 build

Works great, thanks.

[dvdksn]

@bep I saw your comment about ARG/ENV. I pushed a small edit to the first commit to make DART_SASS_VERSION work like the other version args. It makes it easier to maintain, and I like to stick with ENV only when I actually want to set an env var in the runtime container or use it to configure a build tool, like GOOS. Hope it makes sense.

[bep]

t makes it easier to maintain, and I like to stick with ENV only when I actually want to set an env var in the runtime container or use it to configure a build tool, like GOOS. Hope it makes sense.

@dvdksn yea, I removed that comment as I saw that we used ARG for the go versions. We can handle this later, but your argument only makes sense if Docker had a concept of "private ARGs".

As I understand it:

• ARG can be set in argument to docker build and is such part of the "build API"
• ENV is visible in the OS environment of the current shell, but not from the "outside" (e.g. not when running hugo, not as arguments to docker build).

[dvdksn]

Yes I get it, the ability to set these args on the command line is not desirable. But ARG is the better way to go for build-time variables, even if you don't plan on overriding them.

[bep]

But ARG is the better way to go for build-time variables, even if you don't plan on overriding them.

How is it better? My argument is above is that the only practical difference in the "dart sass version" case above is that ARG can be set from the outside, which is a negative; what are the positive sides of ARG that outweighs the negative?

[dvdksn]

In this specific case, no real benefit; it's just more idiomatic. I think it's better to use ENV if you explicitly want an environment variable to configure a build step, or if you want to set an environment variable that persists in the final image and in containers created from it. And use ARG for variables that are only used to influence build execution.

[jmooring]

https://www.docker.com/blog/docker-best-practices-using-arg-and-env-in-your-dockerfiles/#tldr

Also note:

Both ARG and ENV can be overridden from the command line in docker run and docker compose

[bep]

Both ARG and ENV can be overridden from the command line in docker run and docker compose

I have not found any example/documentation about how to pass ENV variables from the command line to docker build.

[dvdksn]

I have not found any example/documentation about how to pass ENV variables from the command line to docker build.

You can't. You can't change the value of ENV outside the Dockerfile itself (unless you use ENV foo=$ARG...)

[jmooring]

Elsewhere in that article the author provides this example (which I have not tested):

$ docker run --rm -e THEENV=bar envtest

[bep]

docker run --rm -e THEENV=bar envtest

Sure, but the discussion above is about docker build and I see no -e option there.

[jmooring]

Gotcha. When reading the article I didn't notice that docker build was excluded.