Skip to content

ci: Automated project builders #3557

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 18 commits into from
Jul 30, 2025
Merged

ci: Automated project builders #3557

merged 18 commits into from
Jul 30, 2025

Conversation

michalChrobot
Copy link
Collaborator

@michalChrobot michalChrobot commented Jul 21, 2025 •
edited
Loading

What

This PR is an initial introduction of Yamato jobs which build our samples and the result can be found in the artifacts of the job under players.
Currently there are 3 samples that we are able to build (I'm open to add more)

The idea here is to run the job from the branch from which we want to test packages (let's say release/1.4.1) and the samples will be build with their manifest pointing to local packages from that branch.
The steps are included here are:

  • cloning the repo
  • modifying project manifest. If the Tools dependency is present I'm ensuring it's the latest one
  • Validating Yamato variable inputs (described at the end of this section)
  • Connecting the project to use Services (needed in NGO case)
  • Disabling or Enabling Burst compilation
  • Copying Builder and assembly definition scripts to the project so we can execute them

Hopefully the scripts are annotated with enough comments that entire setup is clear. Note that when executing the job you have an option to modify Yamato variables to set

  • Editor version which you want to use for the build
  • Decide if you want burst compilation to be enabled or disabled
  • Choose the platform for which you want to build (for now available options are macOS, Win64 and Android)
  • Which scripting backend you want to use (il2cpp or mono)

When the job finishes running you can inspect the job artifacts to get the build (players path) or detailed build logs in case of failure or the build not appearing (logs path)

WHY

The reason for this job is to facilitate/automate Playtesting and improving developers ability to easily test their changes. This PR will help with:

  1. When building bigger samples it can somehow take a lot of time (depending on computer resources) and for Playtesting we usually want to have several combinations (windows, mac, android etc) which makes our machine busy for sometimes several hours during which everything is slow and our work is affected. After this PR it will be possible to use our CI resources to build the project which will allow us to spend our time on some other work during that time
  2. This will create more standardized way of making builds which will hopefully ensure that no steps are missed when creating the build (for example connecting to services in case of NGO)
  3. This may help our developers to validate their changes by facilitating build making process

The main desire behind those changes is the scenario when you trigger appropriate builds when finishing the day and by next morning you have them ready so you can start playtesting right away

Need to know/Additional considerations

  • It is possible that executing such job will take MORE TIME than building the sample on your machine since you need to add the distribution time
  • Keep in mind that as for now the job uses windows machine to make the builds and I'm planning to add mac version/more platforms in another pass but that was my initial setup to not overcomplicate it too much. Note that because of this when opening macOS build you need to follow some additional steps to open the project (namely xattr -c <path/to/application.app> and chmod -R +x <path/to/application.app>). Also you can't build mac with il2cpp (only mono)
  • Some parameters I included as secrets so are not publicly visible

Backport

#3558

@michalChrobot michalChrobot self-assigned this Jul 21, 2025
@michalChrobot michalChrobot mentioned this pull request Jul 21, 2025
Merged
@michalChrobot
Copy link
Collaborator Author

Quick note that I will do the second pass soon where I will make sure that

  • Latest Tools package is used
  • Naming is more descriptive
  • ...

@michalChrobot michalChrobot merged commit 98b2b9f into develop-2.0.0 Jul 30, 2025
25 checks passed
@michalChrobot michalChrobot deleted the automated-project-builders branch July 30, 2025 08:22
michalChrobot added a commit that referenced this pull request Jul 30, 2025
@michalChrobot @NoelStephensUnity
ci: [Backport] Automated project builders (#3558)
2939f8b 
This is a backport of
#3557.
Notice that only projects that we can build with NGOv1.X are included

## Backport

#3557

---------

Co-authored-by: Noel Stephens <[email protected]>
@michalChrobot michalChrobot mentioned this pull request Aug 5, 2025
Merged
@michalChrobot michalChrobot mentioned this pull request Aug 15, 2025
Merged
michalChrobot added a commit that referenced this pull request Sep 3, 2025
@michalChrobot
ci: Setting up conditional CI runs depending on PR comment trigger (#…
3ef5539 
…3580)

This PR aims to address the issue of "overdoing" the CI tests which due
to distribution times often lead to very long wait times.

First thing is that I failed to notice that `targets` and `drafts`
conditions are configured as separate items in a list (see PR job
trigger changes). In our CI, basic triggers in a list are combined with
an OR operator, meaning the job will run if any of the conditions are
met. This lead to test being executed on draft PRs.

What I'm changing is

1. Tests will correctly **not run** on draft PRs and if PR is not
targeting one of specified branches
2. PR trigger tests will execute only if there are changes in package or
project. For for example DOCS only changes no tests will run (in the
future we can improve that if for example we would have a test that
verifies typos etc)

This change should improve our workflow with CI as well as save some
resources for others

**NOTE THAT**
By default the PR trigger it's triggered if

1. PR targets develop or release branches
2. PR is not a draft
3. PR changes files in package or TestProjects folders (doesn't run on
for example DOCS only changes)

Note that in other cases you can trigger it by writing a comment `/ci
ngo` in the PR thread (if for example you want to test it on draft PR)

## Additional stuff
I also used that occasion to remove disable-burst file. We are not using
it and I included more advanced version in
#3557
so if we ever need it we can reuse that one. Because of that I will
remove it to avoid any confusion

## Steps after approval
I will remove the mandatory PR trigger job from branch settings since
now it will not always run (eg. only DOCS changes) and would block PRs
otherwise

## Backports

#3581

## Testing & QA
I verified that

1. PR trigger gets executed correctly when we have package or project
changes
4. I verified that the fact of tests running blocks PR from merging

## Documentation
I added explanation in jobs comments

## Jira ticket
MTT-12903
michalChrobot added a commit that referenced this pull request Sep 12, 2025
@michalChrobot
ci: [NGOv2.X] Automation of NGO releases (#3602)
83063d7 
## Purpose of this PR

This PR automates the releases of NGO package (which can be extended for
other packages since it's quite modular). The job will operate on the
branch from which it will be triggered and by default it will be on the
`develop` branch (job trigger).

For more background note that Netcode 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 run 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](#3557
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 Netcode 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](#3549
the package version of Nshould 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 regenerate
recipes, cleanup changelog and generally prepare our package for
releasing (see result
**[HERE](c9f3f204fc4058df8781dd577b187a117216b544)**)
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` but for the sake of playtesting I used a test
branch). 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.

I created Netcode-Team-Bot with appropriate tokens and marked committer
to point to the bot (when for example making a direct commit to
`develop` with changelog and package version update)
<img width="1782" height="292" alt="image"
src="https://github.com/user-attachments/assets/81e76d5a-b8f3-48f2-985f-40126e6511b8"
/>

The bot will make commits like
<img width="1804" height="164" alt="image"
src="https://github.com/user-attachments/assets/728eb89c-2c59-4b81-8a7e-7f858470b979"
/>

## Jira ticket
https://jira.unity3d.com/browse/MTT-12841

## Documentation
After this gets merged I will add approperiate description of Netcode
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 was tested on
`testing-automated-netcode-releases` branch, the effects of which you
can see as follows (note that instead of `develop-2.0.0` I just used
local branch):

1. I tested for the normal release schedule date (result
**[HERE](https://unity-ci.cds.internal.unity3d.com/job/56127622)**)
2. I tested with empty changelog (result
**[HERE](https://unity-ci.cds.internal.unity3d.com/job/56123485)**)
3. The job itself was green
(**[LINK](https://unity-ci.cds.internal.unity3d.com/job/56127745)**).
4. `release/2.5.1` branch was created with proper initial setup
(**[LINK](https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/tree/release/2.5.1)**),
see latest commits there
5. Changelog and package versions were updated on `develop-2.0.0` branch
(replaced for testing with `testing-automated-netcode-releases`). Notice
that this simulates what will happen on develop branch after this script
runs.
(**[LINK](https://github.com/Unity-Technologies/com.unity.netcode.gameobjects/tree/testing-automated-netcode-releases-2.x)**)
6. Wrench jobs were correctly triggered on the created release branch
(**[LINK](https://unity-ci.cds.internal.unity3d.com/project/1201/branch/release%2F2.5.1/jobDefinition/.yamato%2Fwrench%2Fpromotion-jobs.yml%23publish_dry_run_netcode_gameobjects/recent-jobs?nav=none)**)
7. Builds were triggered from release branch (**[example build
LINK](https://unity-ci.cds.internal.unity3d.com/project/1201/branch/release%2F2.5.1/jobDefinition/.yamato%2Fproject-builders%2Fproject-builders.yml%23build_BossRoom_project/recent-jobs?nav=jobDefinitions)**)

## 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
- **[email protected]** was created to assign
NETCODE_YAMATO_API_KEY to it. Additionally I created tokens for both
GitHubs and when making commit I'm just pointing to this bot as
committer and author.

## Backports
It's backported to
#3603
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@NoelStephensUnity NoelStephensUnity NoelStephensUnity approved these changes

@EmandM EmandM Awaiting requested review from EmandM EmandM is a code owner

Assignees

@michalChrobot michalChrobot

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@michalChrobot @NoelStephensUnity