request to moving location of Dockerfile

[shimwell]

The Dockerfile is located in the CI folder but designed to be built when the current working directory is the root repository folder. The are COPY commands in the dockerfile that need the file to be run from one directory up.

I would be keen to move the Dockerfile to the root repository level.

This will be simpler to build but also save:

• 4 lines of code in .github/workflows/docker_publish.yml
• 4 lines of code in CI/update_docker.sh

If people think this is a good idea I shall put in a PR for this to follow on PR #813

[gonuke]

It seems like all the savings are due to no longer having to manually specify the Dockerfile; is that right?

If so:

• if there is ever more than 1 Dockerfile in the repo, I think it is wise/instructive to specify which one explicitly (even if it is the default)
• let's wait until the transition is over to see how many Dockerfiles we end up with

[shimwell]

Yep you are right, the savings are due to having the Dockerfile with the default name and that default being used by the build command.

[shimwell]

I also think this change would be worth it just to improve the building, currently you must perform the docker build command from the root directory which is not same directory as dockerfile itself. The dockerfile has COPY commands that need viability of the CI folder. Therefore we have a bit of confusing situation where developers really have to think about location, relative location and absolute paths which is an unnecessary complexity.

[gonuke]

Sure- but much of that may disappear as we move through the steps in https://github.com/svalinn/DAGMC/projects/6 - so let's revisit then, and move this further down the list of actions?

[ahnaf-tahmid-chowdhury]

I believe the current Docker setup is tailored for CI builds, and it's a beneficial practice to store different Dockerfiles in separate directories based on their use cases, considering our use of GitHub workflows.

[gonuke]

Historically, I've hoped that our CI Dockerfile can be a useful guide for the average collaborator who wants to build from source. However, it always seems to deteriorate as we make the CI Dockerfile more complicated to support things we do in CI space.

Therefore, I wonder if we should publish an additional Dockerfile that is streamlined but complete for the average collaborator to build directly.

Pro: there is clear guidance for this type of user

Con: we have to ensure that it stays up-to-date/current with other changes - it could be tested separately

[ahnaf-tahmid-chowdhury]

I think our current Dockerfile is sufficient for our needs. Instead of creating an additional Dockerfile, we could focus on updating our documentation to provide clearer guidance for collaborators. Additionally, rather than introducing another separate Dockerfile that requires separate testing, we could explore creating a multi-stage build that produces a smaller image containing only the necessary binary files. This streamlined approach could be more efficient for users without adding complexity to our workflows.

[gonuke]

There are many competing interests here to manage:

1. guidance for users, where documentation can be a substitute
2. providing a robust Dockerfile for users to use with minimal configuration, perhaps our Dockerfile does that if used with no build-args
3. providing a Docker image for users to use, perhaps we can make variations of this by publishing with different sets of build-args

A PR that takes care of these things would be welcome

[ahnaf-tahmid-chowdhury]

@gonuke, I think I should cover this issue on #951 as well.

[gonuke]

I worry that our CI Dockerfile is far more complicated than many users want to worry about. I've always hoped that we could have a single Dockerfile for CI and for the average user, but wonder if we are better off with two?