[NGOv2.X] Automation of NGO releases

[michalChrobot]

Jira Ticket

https://jira.unity3d.com/browse/MTT-12841

Purpose of this PR

This PR automates the releases of NGO package. The job will operate on the branch from which it will be triggered and by default it will be on the develop-2.0.0 branch (job trigger).

For more background note that Tools team sprint last 4 weeks, starting and ending on Wednesday and our goal is to kickstart the release process after last full week of the sprint and preferably release until next Wednesday (end of the sprint). So the goal would be to set-up everything on Saturday (after the week concluded) and have everything ready from Monday morning to Playtest/investigate failures.
As a separate part of this automation, as per THIS PR we are able to trigger builds of our samples so those will also be triggered on the weekend to be ready for playtesting on Monday.

Now with this in mind the process will work in the following way:

1. It runs on weekly schedule but we are interesting on executing it every 4th Saturday (after last full week of the NGO team sprint. Our sprint last 4 weeks). Because of that the first action that this job will do is to run a check to see if the following requirements are satisfied:

• Is this the 4th Saturday since we last released?
• Is NGO CHANGELOG not empty? (no point of making the release is there is nothing to release)
• Is the release branch not yet created?

Before looking at the next steps, please note that as per THIS PR the package version of NGO should always correspond to the current state of the package.

2. If the above is satisfied the next step will be to create the release branch (based on the known package version). The already existing release.py script will be executed there in order to cleanup changelog and generally prepare our package for releasing (see result HERE)
3. The next step will be to trigger all_promotion_related_jobs_promotiontrigger job. In that way when we will set-up packageworks release stream on Monday morning we will already have the results from this job and we can address any potential failures.
4. As a last step the job will create a commit to the local branch (normally develop-2.0.0 but for the sake of playtesting I used this branch) with updated NGO package CHANGELOG and updated package version. The goal with changelog here is we want to avoid changelog divergence if release will take longer then expected. The script will clean the empty sections, assign correct release version and date and then add back the [Unreleased] section template for the purpose of next entries.
   The goal with package version is that we want to indicate that now the package reflects further state (next patch). After this the job will commit this to the branch.

Documentation

After this gets merged I will add approperiate description of NGO release process in https://docs.google.com/document/d/16g9B5jxXeV0zG44Fhax-6Md_gtLoqGVthKQ7LkDvdqM/edit?tab=t.0#heading=h.t1guku6agyev

Testing & QA

Since this automation runs on the same branch on which it's triggered (and just because of job trigger it will be develop-2.0.0 branch) I tested it locally (each script) and entire automation, the effects of which you can see as follows:

1. The job itself was green (LINK). Note that for the sake of this test I modified the dates to allow for release setup on this Tuesday 12.08.2025. Also since the CHANGELOG for Tools was empty I added a temporary entry. I will correct both after showcasing that it works.
2. release/netcode-1.7.1 branch was created with proper initial setup (LINK)
3. Wrench jobs were correctly triggered on the created release branch (LINK)
4. A commit was included on this branch (automated-netcode-releases) with changelog and package version update (LINK). Notice that this simulates what will happen on main branch after this script runs.

On next commits I also have examples of what happens when some conditions are not satisfied.

1. After commit that corrected the changelog to initial state (empty) --> LINK
2. After commit that set the correct date to reflect every 4th Saturday --> LINK

Things to note

• Updating package version to next patch won't be immediately valid (vetting test will still compare it to latest released package version) but it serves the purpose of automating those steps and not needing to remember about it after package is released
• I'm using GITHUB_CDS_TOKEN and NETCODE_YAMATO_API_KEY secrets to handle operations on GitHub an Yamato. Currently I created svc-netcode-sdk@unity3d.com account that will have assigned permissions/secrets for Yamato operations but I'm missing GitHub permissions at the moment (this token doesn't exist in NGO Yamato project yet). Because of that the links in the PR description are pointing to N4E repo, I will run proper checks when I will get that Token

[michalChrobot]

Quick note that until I will get a proper GitHub token for operations the showcase links are to N4E

[michalChrobot]

correct version for NGO