Move builds to vk83

[anton-seaice]

For the repro-ci process, we need to move our default build of access-om3 out of ik11 and into a vk83 folder so it can be accessed by the ci user.

I assume that builds going into /g/data/vk83/apps/spack are put there automatically ? When the builds done through the cosima-spack are triggered manually.

What's the best place we can put them in vk83, until we are ready to move to an access-nri spack based build ?

ping @aidanheerdegen @CodeGat

[CodeGat]

Possibly in /g/data/vk83/prerelease/apps/spack/...? Might need a wider discussion.

[aidanheerdegen]

What's the best place we can put them in vk83, until we are ready to move to an access-nri spack based build ?

Why don't we just move directly to spack deployment?

We have a pre-release we can merge anytime

ACCESS-NRI/ACCESS-OM3#5 (comment)

[CodeGat]

I think from the comments on that PR there might be some updates needed (just in reference to the 'anytime' bit)

[aidanheerdegen]

That is what the point release is for #amirite

[anton-seaice]

We have a pre-release we can merge anytime

ACCESS-NRI/ACCESS-OM3#5 (comment)

There's a couple of open questions on that PR, re:

• hdf5 version
• how to access the dependencies directly (e.g. module load parallelio)

And we haven't really thought through how to use versioning, or provide a easy build system for researchers.

These are all fairly minor things, but the repro-CI is a higher priority at the moment.

[aidanheerdegen]

From my point of view it's just delaying the inevitable and creating extra work for us moving to a half-way solution that we'll abandon anyway.

We should fix any issues that would prevent using the pre-release environment. If that needs to be done ASAP we'll prioritise it.

[dougiesquire]

FWIW, I've been using the ACCESS-NRI spack env for dev work for quite some time without issue

[aidanheerdegen]

FWIW, I've been using the ACCESS-NRI spack env for dev work for quite some time without issue

Good to know, thanks

[anton-seaice]

I think we had agreeement to merge

ACCESS-NRI/ACCESS-OM3#5

I suggest we do that for the 0.3.0 tag of this repo, and then make a new branch at PR in https://github.com/ACCESS-NRI/ACCESS-OM3 and use a branch name like dev-0.3.x ?

Then the build in the prerelease area for dev-0.3.x can be the build in the access-om3-configs branches

[anton-seaice]

I made an 0.3.1 tag of this repo, and used that for the access-nri spack release build instead.

This will get implemented / merged through #194