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
Copy file name to clipboardExpand all lines: Documentation/contributing-workflow.md
+11-5
Original file line number
Diff line number
Diff line change
@@ -7,20 +7,21 @@ You can contribute to .NET Core with issues and PRs. Simply filing issues for pr
7
7
8
8
We use and recommend the following workflow:
9
9
10
-
1. Create an issue for your work.
10
+
1. Create an issue for your work.
11
11
- You can skip this step for trivial changes.
12
12
- Reuse an existing issue on the topic, if there is one.
13
13
- Use [CODE_OWNERS.TXT](../CODE_OWNERS.txt) to find relevant maintainers and @ mention them to ask for feedback on your issue.
14
14
- Get agreement from the team and the community that your proposed change is a good one.
15
-
- If your change adds a new API, follow the [API Review Process](https://github.com/dotnet/corefx/blob/main/Documentation/project-docs/api-review-process.md) (but replace CoreFX with this repo).
15
+
- If your change adds a new API, follow the [API Review Process](https://github.com/dotnet/corefx/blob/main/Documentation/project-docs/api-review-process.md) (but replace CoreFX with this repo).
16
16
- Clearly state that you are going to take on implementing it, if that's the case. You can request that the issue be assigned to you. Note: The issue filer and the implementer don't have to be the same person.
17
17
2. Create a personal fork of the repository on GitHub (if you don't already have one).
18
-
3. Create a branch off of main (`git checkout -b mybranch`).
19
-
- Name the branch so that it clearly communicates your intentions, such as issue-123 or githubhandle-issue.
18
+
3. Create a branch off of main (`git checkout -b mybranch`).
19
+
- Name the branch so that it clearly communicates your intentions, such as issue-123 or githubhandle-issue.
20
20
- Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork.
5. Add new tests corresponding to your change, if applicable.
24
+
If you are having difficulty debugging changes, note that you can add breakpoints into the tests for the library, runtime, or SDK by opening their corresponding workspace folder and launching the debug tab for their tests in VS Code. If you want to breakpoint the code, you'll need to breakpoint the test in typescript, but then every reload add breakpoints to the JS code generated from the typescript code if you want to debug code outside of the tests thesmelves that the tests run.
24
25
6. Build the repository with your changes.
25
26
- Make sure that the builds are clean.
26
27
- Make sure that the tests are all passing, including your new tests.
@@ -37,6 +38,11 @@ Note: It is OK to create your PR as "[WIP]" on the upstream repo before the impl
37
38
38
39
Before making a pull request, be sure to build and test your changes locally with the build script ([windows](https://github.com/dotnet/vscode-dotnet-runtime/blob/main/build.cmd), [mac](https://github.com/dotnet/vscode-dotnet-runtime/blob/main/build.sh)) and test script ([windows](https://github.com/dotnet/vscode-dotnet-runtime/blob/main/test.cmd), [mac](https://github.com/dotnet/vscode-dotnet-runtime/blob/main/test.sh)). To lint your changes, run the test script with the parameter `--tslint`
39
40
41
+
You can also test only a specific set of tests using the following parameters with the test script:
42
+
Test SDK Extension Only: `test sdk` (Tests the SDK extension only.)
43
+
Test SDK Extension Only: `test rnt` (Tests the runtime extension only.)
44
+
Test SDK Extension Only: `test lib` (Tests the library only.)
45
+
40
46
## Building a .VSIX
41
47
42
48
To build an installable .vsix file locally, navigate to the directory containing the extension's package.json (either `vscode-dotnet-runtime-extension` or `vscode-dotnet-sdk-extension`) run the following commands:
@@ -54,7 +60,7 @@ If the CI build fails for any reason, the PR issue will be updated with a link t
54
60
55
61
## PR Feedback
56
62
57
-
Microsoft team and community members will provide feedback on your change. Community feedback is highly valued. You will often see the absence of team feedback if the community has already provided good review feedback.
63
+
Microsoft team and community members will provide feedback on your change. Community feedback is highly valued. You will often see the absence of team feedback if the community has already provided good review feedback.
58
64
59
65
1 or more Microsoft team members will review every PR prior to merge. They will often reply with "LGTM, modulo comments". That means that the PR will be merged once the feedback is resolved. "LGTM" == "looks good to me".
0 commit comments