You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<!-- Replace this block with what this PR does and why. Describe what you'd like reviewers to know, how you applied the engineering principles, and any interesting tradeoffs made. Delete bullet points below that don't apply, and update the changelog section as appropriate. -->
1
+
## Purpose of this PR
2
+
[//]: # (
3
+
Replace this block with what this PR does and why. Describe what you'd like reviewers to know, how you applied the engineering principles, and any interesting tradeoffs made.
4
+
)
2
5
3
-
<!-- Add short version of the JIRA ticket to the PR title (e.g. "feat: new shiny feature [MTT-123]") -->
6
+
### Jira ticket
7
+
_Link to related jira ticket ([Use the smart commits](https://support.atlassian.com/bitbucket-cloud/docs/use-smart-commits/))_
4
8
5
-
## Changelog
9
+
### Changelog
10
+
[//]: #(updated with all public facing changes - API changes, UI/UX changes, behaviour changes, bug fixes. Remove if not relevant.)
6
11
7
12
- Added: The package whose Changelog should be added to should be in the header. Delete the changelog section entirely if it's not needed.
8
-
- Fixed: If you update multiple packages, create a new section with a new header for the other package.
9
-
- Removed/Deprecated/Changed: Each bullet should be prefixed with Added, Fixed, Removed, Deprecated, or Changed to indicate where the entry should go.
10
-
11
-
## Testing and Documentation
12
-
13
-
- No tests have been added.
14
-
- Includes unit tests.
15
-
- Includes integration tests.
16
-
- No documentation changes or additions were necessary.
17
-
- Includes documentation for previously-undocumented public API entry points.
18
-
- Includes edits to existing public API documentation.
13
+
- Fixed: If you update multiple packages, create a new section with a new header for the other package.
14
+
- Removed/Deprecated/Changed: Each bullet should be prefixed with Added, Fixed, Removed, Deprecated, or Changed to indicate where the entry should go
19
15
20
16
<!-- Uncomment and mark items off with a * if this PR deprecates any API:
21
17
### Deprecated API
22
18
- [ ] An `[Obsolete]` attribute was added along with a `(RemovedAfter yyyy-mm-dd)` entry.
23
-
- [ ] An [api updater] was added.
19
+
- [ ] An [api updater](https://confluence.unity3d.com/display/DEV/Obsolete+API+updaters) was added.
24
20
- [ ] Deprecation of the API is explained in the CHANGELOG.
25
21
- [ ] The users can understand why this API was removed and what they should use instead.
26
22
-->
27
23
28
-
## Backport
24
+
## Documentation
25
+
[//]: # (
26
+
This section is REQUIRED and should mention what documentation changes were following the changes in this PR.
27
+
We should always evaluate if the changes in this PR require any documentation changes.
28
+
)
29
29
30
-
<!-- If this is a backport:
31
-
- Add the following to the PR title: "\[Backport\] ..." .
32
-
- Link to the original PR.
33
-
If this needs a backport - state this here
34
-
If a backport is not needed please provide the reason why.
35
-
If the "Backports" section is not present it will lead to a CI test failure.
36
-
-->
30
+
- No documentation changes or additions were necessary.
31
+
- Includes documentation for previously-undocumented public API entry points.
32
+
- Includes edits to existing public API documentation.
33
+
34
+
## Testing & QA
35
+
[//]: # (
36
+
This section is REQUIRED and should describe how the changes were tested and how should they be tested when Playtesting for the release.
37
+
It can range from "edge case covered by unit tests" to "manual testing required and new sample was added".
38
+
Expectation is that PR creator does some manual testing and provides a summary of it here.)
39
+
40
+
### Functional Testing
41
+
[//]: #(If checked, List manual tests that have been performed.)
42
+
_Manual testing :_
43
+
-[ ]`Manual testing done`
44
+
45
+
_Automated tests:_
46
+
-[ ]`Covered by existing automated tests`
47
+
-[ ]`Covered by new automated tests`
48
+
49
+
_Does the change require QA team to:_
50
+
51
+
-[ ]`Review automated tests`?
52
+
-[ ]`Execute manual tests`?
53
+
54
+
If any boxes above are checked, please add QA as a PR reviewer.
55
+
56
+
## Backport
57
+
[//]: # (
58
+
This section is REQUIRED and should link to the PR that targets other NGO version which is either develop or develop-2.0.0 branch
59
+
Add the following to the PR title: "\[Backport\] ..."
60
+
If this is not needed, for example feature specific to NGOv2.X, then just mention this fact.
# This workflow is designed to verify that the pull request description contains a required sections that are important from quality perspective.
2
+
# ## Backport section is important as a reminder to account for backports for anyone that works with NGO repository (to 1.X or 2.X branches respectively).
3
+
# ## Testing & QA section is important to ensure that the PR has appropriate testing coverage and is important when QA will evaluate PRs before Playtesting for the release.
4
+
# ## Documentation section is important to ensure that the documentation is updated with the changes made in the PR.
5
+
6
+
# If any of the sections is missing, the workflow will fail and block the PR from merging, prompting the developer to add those sections to the PR description.
7
+
# The workflow is configured to run when PR is created as well as when it is edited which also counts simple description edits.
8
+
9
+
name: "NGO - PR Verification"
10
+
11
+
on:
12
+
pull_request:
13
+
types: [opened, edited, synchronize, reopened]
14
+
branches:
15
+
- develop
16
+
- develop-2.0.0
17
+
- release/*
18
+
19
+
jobs:
20
+
pr-verification:
21
+
runs-on: ubuntu-latest
22
+
steps:
23
+
- name: Checkout code
24
+
uses: actions/checkout@v4
25
+
26
+
- name: Check PR description
27
+
uses: actions/github-script@v7
28
+
with:
29
+
script: |
30
+
const pr = context.payload.pull_request;
31
+
const body = pr.body || '';
32
+
33
+
// List of mandatory PR sections
34
+
const requiredSections = [
35
+
{
36
+
header: '## Backport',
37
+
description: 'PR description must include a "## Backport" section. Please add this section and provide information about this PR backport to develop or develop-2.0.0 branch respectively or explain why backport is not needed.'
38
+
},
39
+
{
40
+
header: '## Testing & QA',
41
+
description: 'PR description must include a "## Testing & QA" section. Please add this section and provide information about the testing performed for this PR. It can range from adding unit tests to full samples and is needed from QA side to analyze PRs while Playtesting for the release.'
42
+
},
43
+
{
44
+
header: '## Documentation',
45
+
description: 'PR description must include a "## Documentation" section. Please add this section and provide information about the documentation changes made in this PR. It is important to keep the documentation up to date with the code changes.'
# Run API validation to early-detect all new APIs that would force us to release new minor version of the package. Note that for this to work the package version in package.json must correspond to "actual package state" which means that it should be higher than last released version
# Run API validation to early-detect all new APIs that would force us to release new minor version of the package. Note that for this to work the package version in package.json must correspond to "actual package state" which means that it should be higher than last released version
- python Tools/scripts/release.py # Needed to ensure that CHANGELOG is properly formatted for this test due to the fact that we have bumped package version (to properly perform vetting tests)
# Note that we are using internal Unity repo. This means that we may test with newest changes that are not yet released to our users (there are also public versions)
5
+
# Note that for BossRoom 'main' branch supports NGOv1.X and 'develop' branch supports NGOv2.X
# The above line corresponds to https://internaldocs.unity.com/yamato_continuous_integration/usage/templating/
4
+
5
+
# Yamato paths disclaimer:
6
+
# Note that artifacts can get only local paths and since cloned project is in different location, you need to be careful with paths
7
+
# All artifact paths are defined relative to the Yamato source directory (YAMATO_SOURCE_DIR) and are case-sensitive.
8
+
# !!! important “Artifact directory locations” All artifact globs are defined relative to the source directory (YAMATO_SOURCE_DIR). Yamato can’t capture artifacts from outside this directory, so if you need files from elsewhere, you should copy them into your source directory as part of job commands.
9
+
10
+
# Those jobs were created in order to (in most cases) speed up playtesting and development time.
11
+
# The aim is to collect all possible projects that use Netcode for Entities and create a job that will build the project with the given version of N4E package.
12
+
# The package is taken directly from the branch from which the job was triggered. So image triggering the job from release/2.0.0 and release/2.1.0 branch to compare differences
13
+
# Example use case would be to trigger the build job on Sunday so by Monday morning all builds are ready for playtesting. This limits the time a dev/QA has to spend building projects for different configurations (win, mac, Android, scripting backends, burst etc) or simply time necessary for building huge projects (Megacity).
14
+
15
+
# This job takes parameters as scriptable backend configuration, burst compilation, unity editor version and platform.
16
+
# Since Yamato variables can't be restricted to only specific values, the job will validate the parameters passed to it and fail quickly if those are incorrect. In order to see what options are available, please look at the variable name.
17
+
18
+
# Note that for now all of those builds are being made on Windows machine (so for example combination of macOS + il2cpp is expected to fail)
19
+
# TODO: for now all builds are being made on Windows machine, but it would be nice to have a Mac build as well.
- echo Building {{ netcodeProject[0] }} project with Unity version of %UNITY_VERSION%, Scripting backend %SCRIPTING_BACKEND_IL2CPP_MONO%, Burst %BURST_ON_OFF% for platform %PLATFORM_WIN64_MAC_ANDROID%
37
+
38
+
# Clone the external project repository into a specific directory. Notice that branch is also specified.
# Modify the external project's manifest to use the local N4E package from current branch on which this Yamato job is running. (requires python that should be preinstalled in the image)
# Download the Unity Editor version specified in the UNITY_VERSION variable. Il2cpp component is downloaded only if the SCRIPTING_BACKEND_IL2CPP_MONO is set to "il2cpp".
53
+
# TODO: we could download components only if needed
# Build the project using Unity Editor. This will call the given static BuilderScripts method.
62
+
# Ideally, it would be nice to parametrize the BuilderScripts (for example to pass scripting backend as parameter) but -executeMethod only calls static methods without parameters so for now we will have multiple configurations
63
+
# Notice that for Android platform even if mono is selected, il2cpp will be used since mono is not supported for Android builds.
# Because of this we need to ensure that all files are copied to the source directory.
83
+
# TODO: this can be omitted if I can somehow build the project in the source directory (YAMATO_SOURCE_DIR) instead of C:/CompetitiveAction
84
+
- python -c "import os; os.makedirs('./build', exist_ok=True)" # --> Create the build directory if it doesn't exist
85
+
- python -c "import shutil; shutil.copytree('C:/ClonedProject/{{ netcodeProject[1].projectPath }}/build', './build', dirs_exist_ok=True)" # --> Copy the build directory to the source directory (YAMATO_SOURCE_DIR). Remember to copy entire directory and not only exe file
0 commit comments