Determine proper trigger for Payu condaenv deployment

[CodeGat]

Background Currently, we are having to manually run the deployment workflow as a workflow_dispatch event. This is a manual process, and we will need to eventually OK the deployment to an environment anyway. The current requirements note that we should deploy when a new version of Payu is added to the accessnri conda channel, but we are unsure of what the best way is to get that information. Some preliminary solutions follow.

Potential Solutions

• Have it as it currently is (a manual process)
• Have the deployment run when an update to env.yml/git tag is pushed to main, similar to the deployment of ACCESS-OM2 (this separates what payu-org is doing from what we are doing, which is good)
• Somehow subscribe to the accessnri conda channel website itself and trigger when that is updated (would be a very clean solution but ???)
• Piggyback on the existing payu-org/payu CD workflow to workflow_call ACCESS-NRI/payu-condaenvs deploy workflow to note that it has pushed an update to the accessnri conda channel (this would link payu-org to ACCESS-NRI, which would probably be a bad idea for forks of payu-org/payu to have ACCESS-NRI-specific logic. Also, we would have to store ACCESS-NRI PATs to call cross-organisation workflows)
• Schedule a cron job to check the state of the accessnri conda channel every X amount of time. A bit of an ugly solution.
• Fork payu-org/payu to ACCESS-NRI and do one of the above solutions (upstream forks will not get the ACCESS-NRI specific logic, and also having multiple people work on Payu will be easier than, for example, having others work off Person1/payus fork)

Tagging @aidanheerdegen, @jo-basevi and @harshula for input into this matter.

[aidanheerdegen]

After the discussion today it was decided to create a payu fork in the ACCESS-NRI, which will simplify this process. So perhaps this is redundant, or could be massively simplified?

As we will use tagging to identify versions and trigger CD we will need to keep tags consistent with upstream. When tagging we should trigger a PR to upstream to update tags (and code).

Do we want to do all development on the ACCESS-NRI fork? Another possibility is to have issues/PRs etc on upstream, and just pull changes and tags to the ACCESS-NRI fork for deployment.

[CodeGat]

Issues and PRs can definitely still be from/to the upstream (except for the ACCESS-NRI-specific workflows). We're not looking to fork and then forget the upstream - just to make multiple collaborator/CI/CD work more efficiently. Changes that improve Payu are still going to be merged upstream.

[CodeGat]

As it stands now @aidanheerdegen, we will have to close this issue, still using the manual process. It can be reopened later after we discuss it further. The main issue was that we wanted to keep the CD workflows in the ACCESS-NRI/payu repo, but we couldn't find a good way to push tags upstream to payu-org/payu. Keeping the tags in sync between the fork and the upstream was also an issue. Being able to trigger workflows on tags that the upstream didn't have knowledge of also caused headaches. An alternative is to have a manual trigger for the CD workflow when there are tags pushed upstream, or maybe to have a super lightweight VM that runs a cron job that checks for updates to the accessnri conda channel, then sending a workflow_dispatch event.

We implemented a slightly better manual solution where updates to env.yml are checked for validity and also triggers the deployment when the PR is merged.