Mirrors_UI_SDK/GacUI
1
0
Fork 0
mirror of https://github.com/vczh-libraries/Release.git synced 2026-09-28 15:47:13 +08:00
Code Issues Packages Projects Releases Wiki Activity

Sync copilot agent customization files via copilotInitAll.ps1.

Browse Source
This commit is contained in:
vczh
2026-04-30 23:58:13 -07:00
parent ca710a99a6
commit 6b36514bef
18 changed files with 238 additions and 87 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/Guidelines/Building.md
+31 -11
View File
@@ -1,33 +1,38 @@
# Building a Solution
- Go to `Windows Specific` section if you are on Windows.
- Go to `Linux Specific` section if you are on Linux or macOS.
## Windows Specific
- Only run `copilotBuild.ps1` to build a solution.
- DO NOT use msbuild by yourself.
- The script builds all projects in a solution.
## Executing copilotBuild.ps1
### Executing copilotBuild.ps1
Before building, ensure the debugger has stopped.
If there is any error message, it means the debugger is not alive, it is good.
```
& REPO-ROOT\.github\Scripts\copilotDebug_Stop.ps1
```
And then run this script to build the solution:
Run this script to build the solution:
```
cd SOLUTION-ROOT
& REPO-ROOT\.github\Scripts\copilotBuild.ps1
```
## Ensure Target Configuration
It is possible that, before running `copilotBuild.ps1`, the binary to compile is still running or still being debugged. This could cause the linking to fail. You need to check the error message, and in case when it happens:
- Kill `cdb` process first, if there is any.
- The cdb path is stored in `$env:CDBPATH`.
- Avoid running `copilotDebug_Stop.ps1` directly.
- Kill the binary process that is blocked.
- Rebuild, and this issue should gone.
### Ensure Target Configuration
`-Configuration` and `-Platform` arguments are available to specify the target configuration:
- `-Configuration` could be `Debug` (default) or `Release`.
- `-Platform` could be `x64` (default) or `Win32`
- Pick the default option (omit both arguments) when there is no specific requirements.
## The Correct Way to Read Compiler Result
### The Correct Way to Read Compiler Result
- The only source of trust is the raw output of the compiler.
- Wait for the script to finish before reading the log file.
@@ -40,3 +45,18 @@ cd SOLUTION-ROOT
- "0 Warning(s)"
- "0 Error(s)"
- DO NOT delete the log file by yourself.
## Linux Specific
Building only happens on a folder that has a `vmake` file.
- If the repo has only one project, it is in `REPO-ROOT/Test/Linux`.
- If the repo has multiple projects, it is in `REPO-ROOT/Test/Linux/PROJECT-NAME`.
- `PROJECT-NAME` naming is following `PROJECT-NAME.vcxproj`.
You are required to `cd` to such folder before running `build.sh`, otherwise it will fail.
Call `REPO-ROOT/.github/Ubuntu/build.sh` for incremental build.
Call `REPO-ROOT/.github/Ubuntu/build.sh -f` for full rebuild.
`build.sh` will read the local `vmake` configuration file and generate a `makefile` in the same folder before building.
`build.sh` will also run other script files in that folder, run `chmod +x` if any script file is blocked.
Only the "debug x64" configuration is supported on Linux. If you are instructed to build and run other configuration, ignore it.
.github/Guidelines/Debugging.md
+47 -1
View File
@@ -1,4 +1,9 @@
## Debugging a Project
# Debugging a Project
- Go to `Windows Specific` section if you are on Windows.
- Go to `Linux Specific` section if you are on Linux or macOS.
## Windows Specific
Debugging would be useful when you lack necessary information.
In this section I offer you a set of PowerShell scripts that work with CDB (Microsoft's Console Debugger).
@@ -15,6 +20,8 @@ cd SOLUTION-ROOT
start powershell {& REPO-ROOT\.github\Scripts\copilotDebug_Start.ps1 -Executable PROJECT-NAME}
```
If the debugger is already started, this script will fail because the pipe name is occupied. That probably means the last time you forgot to stop the debugger. You can kill `cdb` and the process being debugged, before starting a new debugger.
The `start powershell {}` is necessary; otherwise the script will block the execution forever causing you to wait infinitely.
The script will finish immediately, leaving a debugger running in the background. You can send commands to the debugger.
The process being debugged is paused at the beginning, you are given a chance to set breakpoints.
@@ -32,6 +39,14 @@ This script is also required to run before compiling only when Visual Studio Cod
If there is any error message, it means the debugger is not alive, it is good.
#### Warning
You should never combine `copilotDebug_Stop.ps1` with others in one single powershell call.
It could block you forever if some system thing went wrong.
You should run this script separately, and do not just wait for its input.
The script is supposed to be done very fast, you should keep reading the terminal output parallelly.
And when it seems to never finish, kill the terminal and cdb directly.
### Sending Commands to Debugger
```
@@ -69,3 +84,34 @@ You can also use `dv -rX` to expand "X" levels of fields, the default option is
- Only use **dv** without any parameters.
- DO NOT use **dt**.
- DO NOT use **q**, **qd**, **qq**, **qqd** etc to stop the debugger, always use `copilotDebug_Stop.ps1`.
## Linux Specific
Like building and running, debugging must be performed from the same folder that contains `vmake`:
- If the repo has only one project, it is in `REPO-ROOT/Test/Linux`.
- If the repo has multiple projects, it is in `REPO-ROOT/Test/Linux/PROJECT-NAME`.
- `PROJECT-NAME` naming is following `PROJECT-NAME.vcxproj`.
You are required to `cd` to such folder before launching `lldb`, otherwise relative paths to the binary and source files will be wrong.
`lldb` is going to block the terminal and wait for interaction, you should always start `lldb` in a PTY-backed tool session, for example:
```bash
lldb -- ./Bin/UnitTest /C
```
Keep the session id returned by the tool. Send debugger commands as newline-terminated stdin, one round at a time, and wait for output between rounds.
End the session with:
```text
quit
```
If the debugged process is still running or stuck, send Ctrl-C (`\u0003`), then send:
```text
process kill
quit
```
For non-interactive one-shot debugging, wrap `lldb` with `timeout` so it cannot block forever.
.github/Guidelines/Running-CLI.md
+24 -10
View File
@@ -1,20 +1,17 @@
# Running a CLI Application Project
- Go to `Windows Specific` section if you are on Windows.
- Go to `Linux Specific` section if you are on Linux or macOS.
## Windows Specific
- Only run `copilotExecute.ps1` to run a unit test project.
- DO NOT call executables or scripts yourself.
## Executing copilotExecute.ps1
### Executing copilotExecute.ps1
`PROJECT-NAME` is the name of the project.
Before testing, ensure the debugger has stopped.
If there is any error message, it means the debugger is not alive, it is good.
```
& REPO-ROOT\.github\Scripts\copilotDebug_Stop.ps1
```
And then run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`:
Run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`:
```
cd SOLUTION-ROOT
@@ -29,3 +26,20 @@ cd SOLUTION-ROOT
- `-Configuration` could be `Debug` (default) or `Release`.
- `-Platform` could be `x64` (default) or `Win32`
- Pick the default option (omit both arguments) when there is no specific requirements.
## Linux Specific
Building only happens on a folder that has a `vmake` file.
- If the repo has only one project, it is in `REPO-ROOT/Test/Linux`.
- If the repo has multiple projects, it is in `REPO-ROOT/Test/Linux/PROJECT-NAME`.
- `PROJECT-NAME` naming is following `PROJECT-NAME.vcxproj`.
You are required to `cd` to such folder before running the compiled CLI binary, otherwise it will fail.
After a successful build, `Bin/UnitTest` will be generated as the executable.
If you can'f find it, first check if the build succeeded, and then read `makefile` to find the correct binary file name.
**IMPORTANT**: Always run it async, read terminal output and its return code.
Compiled binary might have bug causing it to trap in a dead looping. DO NOT just wait for it to complete.
If you feel suspicious, you are recommended to kill the process and run it again with the debugger.
Only the "debug x64" configuration is supported on Linux. If you are instructed to build and run other configuration, ignore it.
.github/Guidelines/Running-GacUI.md
+9
View File
@@ -1,3 +1,12 @@
# Running a GacUI Application Project
- Go to `Windows Specific` section if you are on Windows.
- Go to `Linux Specific` section if you are on Linux or macOS.
## Windows Specific
(to edit ...)
## Linux Specific
NOT SUPPORTED
.github/Guidelines/Running-UnitTest.md
+35 -12
View File
@@ -1,20 +1,17 @@
# Running a Unit Test Project
- Go to `Windows Specific` section if you are on Windows.
- Go to `Linux Specific` section if you are on Linux or macOS.
## Windows Specific
- Only run `copilotExecute.ps1` to run a unit test project.
- DO NOT call executables or scripts yourself.
## Executing copilotExecute.ps1
### Executing copilotExecute.ps1
`PROJECT-NAME` is the name of the project.
Before testing, ensure the debugger has stopped.
If there is any error message, it means the debugger is not alive, it is good.
```
& REPO-ROOT\.github\Scripts\copilotDebug_Stop.ps1
```
And then run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`:
Run test cases in `SOLUTION-ROOT\PROJECT-NAME\PROJECT-NAME.vcxproj`:
```
cd SOLUTION-ROOT
@@ -30,7 +27,7 @@ cd SOLUTION-ROOT
- `-Platform` could be `x64` (default) or `Win32`
- Pick the default option (omit both arguments) when there is no specific requirements.
## Ensure Expected Test Files are Selected
### Ensure Expected Test Files are Selected
Test cases are organized in multiple test files.
In `PROJECT-NAME\PROJECT-NAME.vcxproj.user` there is a filter, when it is effective, you will see filtered test files marked with `[SKIPPED]` in `Execute.log`.
@@ -52,7 +49,7 @@ DO NOT delete this `*.vcxproj.user` file.
DO NOT clean the filter (aka delete all `/FILE-NAME.cpp`) by yourself. I put a filter there because running everything is slow and unnecessary for the current task.
Ignore `LocalDebuggerCommandArgumentsHistory` in `*.vcxproj.user`.
## The Correct Way to Read Test Result
### The Correct Way to Read Test Result
- The only source of trust is the raw output of the unit test process.
- Wait for the script to finish before reading the log file.
@@ -68,3 +65,29 @@ Ignore `LocalDebuggerCommandArgumentsHistory` in `*.vcxproj.user`.
- "Passed test files: X/X"
- "Passed test cases: Y/Y"
- DO NOT delete the log file by yourself.
## Linux Specific
Building only happens on a folder that has a `vmake` file.
- If the repo has only one project, it is in `REPO-ROOT/Test/Linux`.
- If the repo has multiple projects, it is in `REPO-ROOT/Test/Linux/PROJECT-NAME`.
- `PROJECT-NAME` naming is following `PROJECT-NAME.vcxproj`.
You are required to `cd` to such folder before running the compiled unit test binary, otherwise it will fail.
After a successful build, `Bin/UnitTest` will be generated as the executable.
If you can'f find it, first check if the build succeeded, and then read `makefile` to find the correct binary file name.
The unit test project supports following command line options:
- `/D`: crash at the first failure, the error message is not printed. This is recommended for debugging.
- `/C`: crash at the first failure and print the error message if possible. This is recommended for usual running.
- `/R`: print all failures without crashing. Be careful to use it because failure cases usually affect following cases, making everything not stable after the first failure.
- `/F:FILENAME.cpp`: file filter.
- If no `/F` appears, all test cpp files will run.
- If one or multiple `/F` appear, only specified cpp files will run.
- `FILENAME.cpp` do not contain file path, and it is case sensitive.
**IMPORTANT**: Always run it async, read terminal output and its return code.
Compiled binary might have bug causing it to trap in a dead looping. DO NOT just wait for it to complete.
If you feel suspicious, you are recommended to kill the process and run it again with the debugger.
When `/D` or `/C` is specified, the unit test binary stops at the first failure, causing it not able to summary how many test cases pass or fail at the end. This would be an obvious signal to tell that it fails.
Only the "debug x64" configuration is supported on Linux. If you are instructed to build and run other configuration, ignore it.