- 
                Notifications
    You must be signed in to change notification settings 
- Fork 460
ci: [Backport] Automated project builders #3558
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.
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
          
     Merged
      
      
    
                
     Merged
            
            
          Conversation
  
    
      This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
      Learn more about bidirectional Unicode characters
    
  
  
    
    
              
                    NoelStephensUnity
  
              
              approved these changes
              
                  
                    Jul 29, 2025 
                  
              
              
            
            
    
  michalChrobot 
      added a commit
      that referenced
      this pull request
    
      Jul 30, 2025 
    
    
      
  
    
      
    
  
## 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** 4. 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) 5. 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
| Quick note that I will do the second pass soon where I will make sure that 
 | 
  
    Sign up for free
    to join this conversation on GitHub.
    Already have an account?
    Sign in to comment
  
      
  Add this suggestion to a batch that can be applied as a single commit.
  This suggestion is invalid because no changes were made to the code.
  Suggestions cannot be applied while the pull request is closed.
  Suggestions cannot be applied while viewing a subset of changes.
  Only one suggestion per line can be applied in a batch.
  Add this suggestion to a batch that can be applied as a single commit.
  Applying suggestions on deleted lines is not supported.
  You must change the existing code in this line in order to create a valid suggestion.
  Outdated suggestions cannot be applied.
  This suggestion has been applied or marked resolved.
  Suggestions cannot be applied from pending reviews.
  Suggestions cannot be applied on multi-line comments.
  Suggestions cannot be applied while the pull request is queued to merge.
  Suggestion cannot be applied right now. Please check back later.
  
    
  
    
This is a backport of #3557. Notice that only projects that we can build with NGOv1.X are included
Backport
#3557