targeting 9c96d17 MOAB commit instead of version 5.1

[bam241]

This is a temporary MOAB update in CI to allow our CI to pass.

this will be change at the next MOAB release

I am building the docker stack right now, I'll push them on request

[bam241]

@gonuke @pshriwise docker build stack is finally built.
let me know what you want to do from there.

[gonuke]

Can you test locally on the new docker stack?

[gonuke]

I wonder if there is a way to structure these files to define a DAGMC_CI_MOAB_VERSION in one place and then refer to it throughout??

[bam241]

I wonder if there is a way to structure these files to define a DAGMC_CI_MOAB_VERSION in one place and then refer to it throughout??

I'll try to think of a way... the problem is that is not probably easy to have bash talking to Circle.... (.circle.yml had to be changed as well....)

In the mean time I'll build and test DAGMC the 4 docker images built against MOAB 9c96d17

[bam241]

successfully tested:

• svalinn/dagmc-ci-ubuntu-18.04-clang-ext-hdf5_1.10.4-moab_9c96d17
• svalinn/dagmc-ci-ubuntu-18.04-gcc-ext-hdf5_1.10.4-moab_9c96d17
• svalinn/dagmc-ci-ubuntu-16.04-clang-ext-hdf5_1.10.4-moab_9c96d17
• svalinn/dagmc-ci-ubuntu-16.04-gcc-ext-hdf5_1.10.4-moab_9c96d17

[gonuke]

I wonder if there is a way to structure these files to define a DAGMC_CI_MOAB_VERSION in one place and then refer to it throughout??

I'll try to think of a way... the problem is that is not probably easy to have bash talking to Circle.... (.circle.yml had to be changed as well....)

In the mean time I'll build and test DAGMC the 4 docker images built against MOAB 9c96d17

A first step might be to use the full branch name Version5.1.0 under normal circumstances. Then checking out master vs develop vs some other branch don't require different logic and name mangling.

[bam241]

Would you like me to implement this here ?
Or think it though and implement this when we switch back to a branch version of MOAB
(it might not make a lot of sense yet as we are building against a specific commit....)

[gonuke]

A couple of optional thoughts on the way to streamlining this change

[gonuke]

doesn't this get overridden by the env variable when called via update_docker.sh. Therefore, this could keep 5.1.0 as the default, but the value is changed in the script?

[gonuke]

I don't know enough about CI/yaml to know if this can be defined only once in this file and reused???

[gonuke]

Would you like me to implement this here ?
Or think it though and implement this when we switch back to a branch version of MOAB
(it might not make a lot of sense yet as we are building against a specific commit....)

See the two small comments I just made and if you think they make sense, we can stop there and work to merge this.

[bam241]

Would you like me to implement this here ?
Or think it though and implement this when we switch back to a branch version of MOAB
(it might not make a lot of sense yet as we are building against a specific commit....)

See the two small comments I just made and if you think they make sense, we can stop there and work to merge this.

I think they make sense, but I'd like to do it cleanly all the way, instead of patching the file one after the other...

I'll prepare a dedicated PR to do this!

[gonuke]

successfully tested:

• svalinn/dagmc-ci-ubuntu-18.04-clang-ext-hdf5_1.10.4-moab_9c96d17
• svalinn/dagmc-ci-ubuntu-18.04-gcc-ext-hdf5_1.10.4-moab_9c96d17
• svalinn/dagmc-ci-ubuntu-16.04-clang-ext-hdf5_1.10.4-moab_9c96d17
• svalinn/dagmc-ci-ubuntu-16.04-gcc-ext-hdf5_1.10.4-moab_9c96d17

I think these are all the tests, right? So then we can merge this and push those images to dockerhub?

[pshriwise]

No comments from me. Thanks for addressing this @bam241!

[gonuke]

Do you want to push these images first and then relaunch tests?

[bam241]

sure will do!

[bam241]

@pshriwise @gonuke docker stack is updated all tests are running fine

[gonuke]

Thanks @bam241