Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow Double Down v1.1.0 Installation in Dockerfile #929

Merged
merged 38 commits into from
Feb 22, 2024
Merged

Conversation

ahnaf-tahmid-chowdhury
Copy link
Member

Pull Request:

This is the upstream version of #928

Changes Made:

  • Enabled Double Down v1.1.0 to be installed in the Dockerfile.
  • Removed double_down from the action and added double_down_version. In the past, the build process used double_down=ON/OFF to build DAGMC, but now DAGMC will default to using Double Down. The version can be specified using double_down_version in the actions.

Details:

  • The Dockerfile has been updated to support the installation of Double Down v1.1.0.
  • Removed the double_down variable from the action and introduced double_down_version for specifying the version during the actions.
  • Previously, DAGMC was built using double_down=ON/OFF, but now it defaults to using Double Down.
  • Various variables have been adjusted for consistency and improved readability.

This PR streamlines the installation process, makes the Dockerfile compatible with Double Down v1.1.0, and provides flexibility in choosing the version in the actions.

@ahnaf-tahmid-chowdhury
Copy link
Member Author

Not sure why Linux Build/Test is failing. It should use the latest docker image.

Copy link
Member

@pshriwise pshriwise left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of really tiny nit picks here @ahnaf-tahmid-chowdhury. Thanks for updating the CI variables/Docker build args to use a consistent syntax. I think that's a nice improvement.

I'll let @gonuke chime in on using double-down by default. My take is that we'd want to leave the default set to MOAB since double-down is an optional dependency of DAGMC.

.github/workflows/linux_upstream_test_double_down.yml Outdated Show resolved Hide resolved
.github/workflows/linux_upstream_test_moab.yml Outdated Show resolved Hide resolved
@pshriwise pshriwise mentioned this pull request Dec 10, 2023
Co-authored-by: Patrick Shriwise <[email protected]>
Co-authored-by: Patrick Shriwise <[email protected]>
Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of additional changes requested.

CI/Dockerfile Show resolved Hide resolved
CI/Dockerfile Outdated Show resolved Hide resolved
@gonuke
Copy link
Member

gonuke commented Dec 11, 2023

I'm happy to revisit the plan for testing with Double Down. As @pshriwise says above, it is an optional dependency. Therefore, we should definitely be testing without it. What is not clear is whether we want to require that every change builds successfully with DD. We could, but perhaps not the full matrix - just add it as one or two special cases.

@ahnaf-tahmid-chowdhury
Copy link
Member Author

Hi @gonuke and @pshriwise,

It seems that both Double Down and Geant4 are now optional for DAGMC. I have made some changes in this version. If the geant4_version or double_down_version is not set, workflow will automatically disable their build. Additionally, Docker images will be created with their names appended to the version string.

Since I've made several changes, please review from the beginning.

@ahnaf-tahmid-chowdhury ahnaf-tahmid-chowdhury marked this pull request as draft December 11, 2023 09:46
@ahnaf-tahmid-chowdhury ahnaf-tahmid-chowdhury marked this pull request as ready for review December 11, 2023 17:21
@gonuke
Copy link
Member

gonuke commented Dec 23, 2023

I've just noticed a couple of concepts that have been forgotten in this update.

Even though GEANT4 is an optional dependency, we always want to test with GEANT4 in CI. There is no reason not to. It should never be off. It also leads to needing fewer Docker images in our container registry.

Also, Embree was always installed as part of the external dependencies for a few reasons, and independent of whether or not Double Down is being tested. Again, since this is for CI, there is reason not to have Embree always installed. If always installing it, it is best to do it early in the build since it changes least often and then the Docker cache doesn't have to rebuild it if/when MOAB changes.

It is easy to forget these things or not realize why they are true, so I suppose I should leave more comments for some of these subtle decisions.

@ahnaf-tahmid-chowdhury
Copy link
Member Author

If it is necessary to build Geant4 every time, we can keep this always on. Moreover, with this update we can use both mode with matrix. Same rule for Double Down.

If Embree is always required to be installed (optional part of DAGMC) we can make remove the current condisions, also, we can make similar method for Embree as we have done for Geant4 and Double Down.

@gonuke
Copy link
Member

gonuke commented Dec 23, 2023

I think it makes sense to always build GEANT4, Embree & Double Down, but we don't always need to test with them. For CI purposes, there is no down side to having the maximum number of dependencies installed, and then use them in different ways during testing.

@ahnaf-tahmid-chowdhury
Copy link
Member Author

As I have already mentioned, the current update can let us do both. Yes, this approach is using some extra conditions, but it may cost an unnoticeable time to process, indeed it may speed up the build process in some cases. However, if you are satisfied with extra builds, I can remove all the conditions and may be hardcoded the OFF value to the DAGMC build.

Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this still me need a rebase at least for the CHANGELOG?

@@ -7,9 +7,13 @@ DAGMC Changelog
Next version
====================

v3.2.3
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Something looks wrong here relative to the released version v3.2.3 - maybe needs a rebase?

@gonuke
Copy link
Member

gonuke commented Dec 23, 2023

As I have already mentioned, the current update can let us do both. Yes, this approach is using some extra conditions, but it may cost an unnoticeable time to process, indeed it may speed up the build process in some cases. However, if you are satisfied with extra builds, I can remove all the conditions and may be hardcoded the OFF value to the DAGMC build.

Maybe it is OK in its current form. The only issue I'm not sure about is that we only build Embree when DD is on, and we do so after MOAB. If we did it always (whether or not DD is on) as part of the external dependencies (e.g. near GEANT or HDF5) it would make the test for DD faster because it would not always have to also build Embree.

@ahnaf-tahmid-chowdhury
Copy link
Member Author

Actually, Embree will be built only once for the docker tag that contains double_down_[version] (different tag). It will not be built every time if we do not modify anything in the Docker file. Even if we change the version of Double Down, it will not be built, as it comes before Double Down. When considering the order of dependencies we build first, we may need to take into account which of them generally gets updated often. So, let me know how do I reorder them.

@ahnaf-tahmid-chowdhury
Copy link
Member Author

Is there anything more to change on this? Or, I think @gonuke is awaiting @pshriwise's response on using find_package through CMake to specify the minimum version of DD.

@ahnaf-tahmid-chowdhury
Copy link
Member Author

@gonuke, do you like to enable testing for DD v1.1.0 as you have mentioned earlier?

Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One more change and still waiting on @pshriwise to chime in

CI/Dockerfile Outdated Show resolved Hide resolved
@@ -90,6 +90,10 @@ macro (dagmc_setup_options)

if (DOUBLE_DOWN)
find_package(DOUBLE_DOWN REQUIRED)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ping @pshriwise

@ahnaf-tahmid-chowdhury
Copy link
Member Author

@gonuke, Please note DD tests are turned off. Let me know, if you like to turn this on to v1.1.0

Copy link
Member

@gonuke gonuke left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We've been churning away at this for a while, so it probably makes sense to recap what the goals of this PR are:

  • Building CI testing images
    • install a valid version of Double Down in all CI testing images - currently v1.1.0 but NOT v1.0.0
    • test the CI testing images with DAGMC both with DD and without
  • testing for each PR
    • test with DD and without for each PR
  • testing for merge
    • test DD develop branch upon merge as advisory

In addition, there is a lot of cleanup of build-arg variables and other variables.

Given all this, in addition to the code comments, I think we should turn on DD testing in linux_build_test.yml

10.7.4,
11.1.2
]
double_down_version : [
v1.0.0,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We know this version fails, so we should remove it.

We may also want to add off to this list so we can test without DD.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have added this to check if CMake 3.16 shows any error messages since it is lower than 1.1.0, but it just passed. That means, CMake will also get failed for Geant4 as well.

10.7.4,
11.1.2
]
double_down_version : [
off
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This matrix should probably match the matrix above to make sure all the right images exist.

@gonuke
Copy link
Member

gonuke commented Feb 22, 2024

Needs a rebase following the recent housekeeping update

@gonuke
Copy link
Member

gonuke commented Feb 22, 2024

I think we've addressed your comment @pshriwise and are ready to merge

Copy link
Member

@pshriwise pshriwise left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for your effort here @ahnaf-tahmid-chowdhury! And thanks to @gonuke for the thorough discussion.

@gonuke gonuke merged commit bdd5b79 into develop Feb 22, 2024
20 checks passed
@@ -43,11 +43,24 @@ runs:
- name: Installing Dependencies in Docker image
uses: firehed/multistage-docker-build-action@v1
with:
repository: ghcr.io/${{ github.repository_owner }}/dagmc-ci-ubuntu-${{ inputs.ubuntu_version }}-${{ inputs.compiler}}-geant4_${{ inputs.geant_version }}-hdf5_${{ inputs.hdf5_version }}-moab_${{ inputs.moab_version }}
repository: >
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ahnaf-tahmid-chowdhury : This change introduced a failure - you can’t split this across multiple lines - that we didn’t review carefully enough in the PR. Please submit an update to fix this.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's wait for all the new Docker images to finish building, then we can rerun the Linux tests to see what happens.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I looked at the failed logs and saw that the failure is because this multi-line container name is resolving with spaces in the name, so it definitely needs to be fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants