Disable Payu metadata.yaml functionality

[dougiesquire]

Functionality was recently added in Payu to automatically generate and commit a metadata.yaml file when setting up an experiment. This is great for users wanting to run an experiment following Payu's recommended practices, but it makes it easy to accidentally add an unwanted commit when developing configs. We can turn it off by setting in the config.yaml:

metadata:
  enable: False

I propose we do this while we're still actively developing our configs.

[anton-seaice]

I guess maybe we don't want this for releases? I don't really understand how releases work in git, can we configure so this to be removed automatically for a release? (Maybe we just defer that to the release team?)

[micaeljtoliveira]

@anton-seaice From the point of view of git, a release is usually just a tag. Then it's up to the developers to decide how the corresponding commit is crafted. Often this will require going through a list of required tasks, which can be automated and/or done manually. Re-enabling the metadata functionality would then be one of those tasks.

[anton-seaice]

Yeah - do we have a checklist or something for those tasks ?

[micaeljtoliveira]

No, but it would be a good idea to write one down. This could go in the OM3 wiki or one could create a github issue template including such list.

[anton-seaice]

one could create a github issue template including such list.

Would this be specific to doing a release? Or would this be the template for all new issues?

[micaeljtoliveira]

It should be specific for doing releases. This is possible, as you can have more than one template for issues. Users can then choose which template to use when opening the issue.

[anton-seaice]

Would the issue templates only exist in the main branch of the repos ?

[micaeljtoliveira]

Yes, I believe github only picks up the templates from the default branch.

[anton-seaice]

I think we need a release procedure actually.

I guess you are checking out main, manually editing and committing with a tag added (e.g. ACCESS-NRI/access-om3-configs@43f0b87). And then using the tag for a release through the web interface?

So we need some instructions to say that and reminder the developer that the versions are all set in the right places?

(I guess we could skip the procedure, and just make an automation?)

[micaeljtoliveira]

I think we need a release procedure actually.

Yes.

I guess you are checking out main, manually editing and committing with a tag added (e.g. ACCESS-NRI/access-om3-configs@43f0b87).

No, I was actually using a release branch. This is a very common git workflow for releases and is necessary if one wants to do hotfix releases (releases based on a previous release that only include bug fixes and no new features).

And then using the tag for a release through the web interface?

Yes.

So we need some instructions to say that and reminder the developer that the versions are all set in the right places?

Yes. My suggestion was to put those instructions in the issue template.

(I guess we could skip the procedure, and just make an automation?)

You should not completely automate this, as it's a good idea to have an associated PR so one can perform specific CI checks. That's another reason to use a release branch, as one can configure github actions to perform specific checks based on some branch name pattern (e.g., release-*).

[anton-seaice]

Yes. My suggestion was to put those instructions in the issue template.

I am closer to understanding this now :) Does this mean to release the configs we would need an issue for every supported config (plus the one for the build) ?

[anton-seaice]

Ok - I created #146 to catch the release stuff. Happy for this change to be done.

[micaeljtoliveira]

Does this mean to release the configs we would need an issue for every supported config (plus the one for the build) ?

You don't need to have an issue per config, but it might be convenient. I think that's something you would have to try and see how it works.

[anton-seaice]

Close through linked PRs