nx-tools

nx-tools copied to clipboard

I have multiple apps that have a docker build target using your library. For some reason, at times when my ci is building all the images npx nx run-many --target=docker, the dockerfile for a given app will be used in another app. I have confirmed configuration values and nothing is amiss in that regard. When I rerun the ci pipeline in gitlab it will then go away - or not. It is random as far as I can tell. This is a huge issue as it results in pushing the WRONG ARTIFACTS to the image, resulting in deploying the wrong app to the wrong domain.

@patrickmichalina Can you provide a minimum reproducible repository?...

I can confirm this issue occurs in @nx-tools/[email protected]. When building multiple apps and pushing images, sometimes Dockerfile from a different app gets picked up. It's non-deterministic and the issue persists even when skipping Nx caching features.

When building and pushing images like so:

npx nx run app-a:build  --configuration=production --skip-nx-cache
npx nx run app-b:build  --configuration=production --skip-nx-cache
npx nx run app-c:build  --configuration=production --skip-nx-cache

npx nx run app-a:docker --configuration=production --skip-nx-cache
npx nx run app-b:docker --configuration=production --skip-nx-cache
npx nx run app-c:docker --configuration=production --skip-nx-cache

we've observed that the app-c docker build sometimes picks up the Dockerfile from the app-b directory. Every app has its own docker file under apps/app-x/Dockerfile. Configuration in the project.json file is standardized for all apps:

{
        "docker": {
            "executor": "@nx-tools/nx-docker:build",
            "options": {
                "push": false,
                "metadata": {
                    "images": ["app-x"],
                    "tags": [
                        "type=schedule",
                        "type=ref,event=branch",
                        "type=ref,event=tag",
                        "type=ref,event=pr",
                        "type=sha",
                        "type=sha,format=long",
                        "latest"
                    ]
                }
            },
            "configurations": {
                "production": {
                    "push": true,
                    "engine": "docker",
                    "metadata": {
                        "images": ["docker-registry.server/containers/app-x"],
                        "cache-from": ["type=gha"],
                        "cache-to": ["type=gha,mode=max"],
                        "tags": [
                            "type=schedule",
                            "type=ref,event=branch",
                            "type=ref,event=tag",
                            "type=ref,event=pr",
                            "type=sha",
                            "type=sha,format=long",
                            "latest"
                        ]
                    }
                },
                "staging": {
                    "push": true,
                    "engine": "docker",
                    "metadata": {
                        "images": ["docker-registry.server/containers/app-x"],
                        "cache-from": ["type=gha"],
                        "cache-to": ["type=gha,mode=max"],
                        "tags": [
                            "type=schedule",
                            "type=ref,event=branch",
                            "type=ref,event=tag",
                            "type=ref,event=pr",
                            "type=sha",
                            "type=sha,format=long",
                            "latest"
                        ]
                    }
                }
            }
        }
}

Any ideas on what might be occurring here or even how to mitigate the issue for the time being?

Are you sure building images in parallel is supported? You can try —parallel=1

Thanks for the tip, it might be so, looked like some kind of race condition. I've moved on from the project, but in the end we went with a build -> docker -> clean cycle, which helped.

@pkchv I your case you are seems to be using a deprecated version of the package, please use @nx-tools/nx-container which add support for kaniko and podman too...

With kaniko parallels builds are not supported but for docker should not be problem 🤔 ... Please provide a repo to reproduce the error

@patrickmichalina please can you share your targets config and a repo to reproduce the problem?... Also you can use the file option to add the docker file path in the target config so the executor will use that file instead to try to find the default one inside the project folder...

@gperdomor sorry for the late response. I haven't seen this happening in awhile. I ended up writing e2e docker tests to ensure images would never be deployed with the wrong artifacts. It stopped awhile ago. Maybe time to close this?