Skip to content

Commit ffb4e54

Browse files
committed
Merge branch 'main' of github.com:github/docs-internal into remove-fpt
2 parents ecaec6e + fb0f384 commit ffb4e54

37 files changed

Lines changed: 13809 additions & 610 deletions

.github/workflows/autoupdate-branch.yml

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,7 @@ jobs:
77
autoupdate:
88
if: github.repository == 'github/docs-internal' || github.repository == 'github/docs'
99
name: autoupdate
10-
runs-on: ubuntu-18.04
10+
runs-on: ubuntu-latest
1111
steps:
1212
- uses: docker://chinthakagodawita/autoupdate-action:v1
1313
env:

.github/workflows/codeql.yml

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -2,9 +2,11 @@ name: CodeQL analysis
22

33
on:
44
push:
5-
branches: main
5+
branches:
6+
- main
67
pull_request:
7-
branches: main
8+
branches:
9+
- main
810
paths:
911
- '**/*.js'
1012
- '.github/workflows/codeql.yml'

README.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@ We accept a lot of [different contributions](CONTRIBUTING.md/#types-of-contribut
1818

1919
#### Click **make a contribution** from docs
2020

21-
As you're using the GitHub Docs, you may find something in an article that you'd like to add to, update, or change. Click on **make a contribution** to navigate directly to that article in the codebase, so that you can begin making your contribution.
21+
As you're using GitHub Docs, you may find something in an article that you'd like to add to, update, or change. Click on **make a contribution** to navigate directly to that article in the codebase, so that you can begin making your contribution.
2222

2323
<img src="./assets/images/contribution_cta.png" width="400">
2424

66.6 KB
Loading
Binary file not shown.
Lines changed: 248 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,248 @@
1+
---
2+
title: Building and testing .NET
3+
intro: You can create a continuous integration (CI) workflow to build and test your .NET project.
4+
product: '{% data reusables.gated-features.actions %}'
5+
versions:
6+
free-pro-team: '*'
7+
enterprise-server: '>=2.22'
8+
---
9+
10+
### Introduction
11+
12+
This guide shows you how to build, test, and publish a .NET package.
13+
14+
{% data variables.product.prodname_dotcom %}-hosted runners have a tools cache with preinstalled software, which includes the .NET Core SDK. For a full list of up-to-date software and the preinstalled versions of .NET Core SDK, see [software installed on {% data variables.product.prodname_dotcom %}-hosted runners](/actions/reference/specifications-for-github-hosted-runners).
15+
16+
### Prerequisites
17+
18+
You should already be familiar with YAML syntax and how it's used with {% data variables.product.prodname_actions %}. For more information, see "[Workflow syntax for {% data variables.product.prodname_actions %}](/actions/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions)."
19+
20+
We recommend that you have a basic understanding of the .NET Core SDK. For more information, see [Getting started with .NET](https://dotnet.microsoft.com/learn).
21+
22+
### Starting with the .NET workflow template
23+
24+
{% data variables.product.prodname_dotcom %} provides a .NET workflow template that should work for most .NET projects, and this guide includes examples that show you how to customize this template. For more information, see the [.NET workflow template](https://github.com/actions/setup-dotnet).
25+
26+
To get started quickly, add the template to the `.github/workflows` directory of your repository.
27+
28+
{% raw %}
29+
```yaml
30+
name: dotnet package
31+
32+
on: [push]
33+
34+
jobs:
35+
build:
36+
37+
runs-on: ubuntu-latest
38+
strategy:
39+
matrix:
40+
dotnet-version: [ '2.2.103', '3.0', '3.1.x' ]
41+
42+
steps:
43+
- uses: actions/checkout@v2
44+
- name: Setup .NET Core SDK ${{ matrix.dotnet }}
45+
uses: actions/setup-dotnet@v1.6.0
46+
with:
47+
dotnet-version: {{ matrix.dotnet-version }}
48+
- name: Install dependencies
49+
run: dotnet restore
50+
- name: Build
51+
run: dotnet build --configuration Release --no-restore
52+
- name: Test
53+
run: dotnet test --no-restore --verbosity normal
54+
```
55+
{% endraw %}
56+
57+
### Specifying a .NET version
58+
59+
To use a preinstalled version of the .NET Core SDK on a {% data variables.product.prodname_dotcom %}-hosted runner, use the `setup-dotnet` action. This action finds a specific version of .NET from the tools cache on each runner, and adds the necessary binaries to `PATH`. These changes will persist for the remainder of the job.
60+
61+
The `setup-dotnet` action is the recommended way of using .NET with {% data variables.product.prodname_actions %}, because it ensures consistent behavior across different runners and different versions of .NET. If you are using a self-hosted runner, you must install .NET and add it to `PATH`. For more information, see the [`setup-dotnet`](https://github.com/marketplace/actions/setup-dotnet).
62+
63+
#### Using multiple .NET versions
64+
65+
{% raw %}
66+
```yaml
67+
name: dotnet package
68+
69+
on: [push]
70+
71+
jobs:
72+
build:
73+
74+
runs-on: ubuntu-latest
75+
strategy:
76+
matrix:
77+
dotnet: [ '2.2.103', '3.0', '3.1.x' ]
78+
79+
steps:
80+
- uses: actions/checkout@v2
81+
- name: Setup dotnet ${{ matrix.dotnet-version }}
82+
uses: actions/setup-dotnet@v1.6.0
83+
with:
84+
dotnet-version: ${{ matrix.dotnet-version }}
85+
# You can test your matrix by printing the current dotnet version
86+
- name: Display dotnet version
87+
run: dotnet --version
88+
```
89+
{% endraw %}
90+
91+
#### Using a specific .NET version
92+
93+
You can configure your job to use a specific version of .NET, such as `3.1.3`. Alternatively, you can use semantic version syntax to get the latest minor release. This example uses the latest minor release of .NET 3.
94+
95+
{% raw %}
96+
```yaml
97+
- name: Setup .NET 3.x
98+
uses: actions/setup-dotnet@v2
99+
with:
100+
# Semantic version range syntax or exact version of a dotnet version
101+
dotnet-version: '3.x'
102+
```
103+
{% endraw %}
104+
105+
### Installing dependencies
106+
107+
{% data variables.product.prodname_dotcom %}-hosted runners have the NuGet package manager installed. You can use the dotnet CLI to install dependencies from the NuGet package registry before building and testing your code. For example, the YAML below installs the `Newtonsoft` package.
108+
109+
{% raw %}
110+
```yaml
111+
steps:
112+
- uses: actions/checkout@v2
113+
- name: Setup dotnet
114+
uses: actions/setup-dotnet@v1.6.0
115+
with:
116+
dotnet-version: '3.1.x'
117+
- name: Install dependencies
118+
run: dotnet add package Newtonsoft.Json --version 12.0.1
119+
```
120+
{% endraw %}
121+
122+
{% if currentVersion == "free-pro-team@latest" %}
123+
124+
#### Caching dependencies
125+
126+
You can cache NuGet dependencies using a unique key, which allows you to restore the dependencies for future workflows with the [`cache`](https://github.com/marketplace/actions/cache) action. For example, the YAML below installs the `Newtonsoft` package.
127+
128+
For more information, see "[Caching dependencies to speed up workflows](/actions/guides/caching-dependencies-to-speed-up-workflows)."
129+
130+
{% raw %}
131+
```yaml
132+
steps:
133+
- uses: actions/checkout@v2
134+
- name: Setup dotnet
135+
uses: actions/setup-dotnet@v1.6.0
136+
with:
137+
dotnet-version: '3.1.x'
138+
- uses: actions/cache@v2
139+
with:
140+
path: ~/.nuget/packages
141+
# Look to see if there is a cache hit for the corresponding requirements file
142+
key: ${{ runner.os }}-nuget-${{ hashFiles('**/packages.lock.json') }}
143+
restore-keys: |
144+
${{ runner.os }}-nuget
145+
- name: Install dependencies
146+
run: dotnet add package Newtonsoft.Json --version 12.0.1
147+
```
148+
{% endraw %}
149+
150+
{% note %}
151+
152+
**Note:** Depending on the number of dependencies, it may be faster to use the dependency cache. Projects with many large dependencies should see a performance increase as it cuts down the time required for downloading. Projects with fewer dependencies may not see a significant performance increase and may even see a slight decrease due to how NuGet installs cached dependencies. The performance varies from project to project.
153+
154+
{% endnote %}
155+
156+
{% endif %}
157+
158+
### Building and testing your code
159+
160+
You can use the same commands that you use locally to build and test your code. This example demonstrates how to use `dotnet build` and `dotnet test` in a job:
161+
162+
{% raw %}
163+
```yaml
164+
steps:
165+
- uses: actions/checkout@v2
166+
- name: Setup dotnet
167+
uses: actions/setup-dotnet@v1.6.0
168+
with:
169+
dotnet-version: '3.1.x'
170+
- name: Install dependencies
171+
run: dotnet restore
172+
- name: Build
173+
run: dotnet build
174+
- name: Test with the dotnet CLI
175+
run: dotnet test
176+
```
177+
{% endraw %}
178+
179+
### Packaging workflow data as artifacts
180+
181+
After a workflow completes, you can upload the resulting artifacts for analysis. For example, you may need to save log files, core dumps, test results, or screenshots. The following example demonstrates how you can use the `upload-artifact` action to upload test results.
182+
183+
For more information, see "[Persisting workflow data using artifacts](/github/automating-your-workflow-with-github-actions/persisting-workflow-data-using-artifacts)."
184+
185+
{% raw %}
186+
```yaml
187+
name: dotnet package
188+
189+
on: [push]
190+
191+
jobs:
192+
build:
193+
194+
runs-on: ubuntu-latest
195+
strategy:
196+
matrix:
197+
dotnet-version: [ '2.2.103', '3.0', '3.1.x' ]
198+
199+
steps:
200+
- uses: actions/checkout@v2
201+
- name: Setup dotnet
202+
uses: actions/setup-dotnet@v1.6.0
203+
with:
204+
dotnet-version: ${{ matrix.dotnet-version }}
205+
- name: Install dependencies
206+
run: dotnet restore
207+
- name: Test with dotnet
208+
run: dotnet test --logger trx --results-directory "TestResults-${{ matrix.dotnet-version }}"
209+
- name: Upload dotnet test results
210+
uses: actions/upload-artifact@v2
211+
with:
212+
name: dotnet-results-${{ matrix.dotnet-version }}
213+
path: TestResults-${{ matrix.dotnet-version }}
214+
# Use always() to always run this step to publish test results when there are test failures
215+
if: ${{ always() }}
216+
```
217+
{% endraw %}
218+
219+
### Publishing to package registries
220+
221+
You can configure your workflow to publish your Dotnet package to a package registry when your CI tests pass. You can use repository secrets to store any tokens or credentials needed to publish your binary. The following example creates and publishes a package to {% data variables.product.prodname_registry %} using `dotnet core cli`.
222+
223+
{% raw %}
224+
```yaml
225+
name: Upload dotnet package
226+
227+
on:
228+
release:
229+
types: [created]
230+
231+
jobs:
232+
deploy:
233+
runs-on: ubuntu-latest
234+
steps:
235+
- uses: actions/checkout@v2
236+
- uses: actions/setup-dotnet@v1
237+
with:
238+
dotnet-version: '3.1.x' # SDK Version to use.
239+
source-url: https://nuget.pkg.github.com/<owner>/index.json
240+
env:
241+
NUGET_AUTH_TOKEN: ${{secrets.GITHUB_TOKEN}}
242+
- run: dotnet build <my project>
243+
- name: Create the package
244+
run: dotnet pack --configuration Release <my project>
245+
- name: Publish the package to GPR
246+
run: dotnet nuget push <my project>/bin/Release/*.nupkg
247+
```
248+
{% endraw %}

content/actions/guides/index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -28,6 +28,7 @@ layout: product-sublanding
2828
<!-- {% link_in_list /about-continuous-integration %} -->
2929
<!-- {% link_in_list /setting-up-continuous-integration-using-workflow-templates %} -->
3030
<!-- {% link_in_list /building-and-testing-nodejs %} -->
31+
<!-- {% link_in_list /building-and-testing-net %} -->
3132
<!-- {% link_in_list /building-and-testing-powershell %} -->
3233
<!-- {% link_in_list /building-and-testing-python %} -->
3334
<!-- {% link_in_list /building-and-testing-ruby %} -->

content/github/managing-security-vulnerabilities/configuring-dependabot-security-updates.md

Lines changed: 7 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -42,17 +42,19 @@ If security updates are not enabled for your repository and you don't know why,
4242

4343
### Managing {% data variables.product.prodname_dependabot_security_updates %} for your repositories
4444

45-
You can enable or disable {% data variables.product.prodname_dependabot_security_updates %} for an individual repository.
45+
You can enable or disable {% data variables.product.prodname_dependabot_security_updates %} for an individual repository (see below).
4646

4747
You can also enable or disable {% data variables.product.prodname_dependabot_security_updates %} for all repositories owned by your user account or organization. For more information, see "[Managing security and analysis settings for your user account](/github/setting-up-and-managing-your-github-user-account/managing-security-and-analysis-settings-for-your-user-account)" or "[Managing security and analysis settings for your organization](/github/setting-up-and-managing-organizations-and-teams/managing-security-and-analysis-settings-for-your-organization)."
4848

4949
{% data variables.product.prodname_dependabot_security_updates %} require specific repository settings. For more information, see "[Supported repositories](#supported-repositories)."
5050

51+
#### Enabling or disabling {% data variables.product.prodname_dependabot_security_updates %} for an individual repository
52+
5153
{% data reusables.repositories.navigate-to-repo %}
52-
{% data reusables.repositories.sidebar-security %}
53-
{% data reusables.repositories.sidebar-dependabot-alerts %}
54-
1. Above the list of alerts, use the drop-down menu and select or unselect **{% data variables.product.prodname_dependabot %} security updates**.
55-
![Drop-down menu with the option to enable {% data variables.product.prodname_dependabot_security_updates %}](/assets/images/help/repository/enable-dependabot-security-updates-drop-down.png)
54+
{% data reusables.repositories.sidebar-settings %}
55+
{% data reusables.repositories.navigate-to-security-and-analysis %}
56+
1. Under "Configure security and analysis features", to the right of "{% data variables.product.prodname_dependabot %} security updates", click **Enable** or **Disable**.
57+
!["Configure security and analysis features" section with button to enable {% data variables.product.prodname_dependabot_security_updates %}](/assets/images/help/repository/enable-dependabot-security-updates-button.png)
5658

5759
### Further reading
5860

content/packages/learn-github-packages/about-github-packages.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -152,7 +152,7 @@ For more information, see:
152152

153153
### Managing packages
154154

155-
You can delete a version of a private package on {% data variables.product.product_name %} or using the GraphQL API. When you use the GraphQL API to query and delete private packages, you must use the same token you use to authenticate to {% data variables.product.prodname_registry %}. For more information, see "[Deleting a package](/packages/manage-packages/deleting-a-package)" and "[Forming calls with GraphQL](/graphql/guides/forming-calls-with-graphql)."
155+
You can delete a version of a private package in the {% data variables.product.product_name %} user interface or using the GraphQL API. When you use the GraphQL API to query and delete private packages, you must use the same token you use to authenticate to {% data variables.product.prodname_registry %}. For more information, see "[Deleting a package](/packages/manage-packages/deleting-a-package)" and "[Forming calls with GraphQL](/graphql/guides/forming-calls-with-graphql)."
156156

157157
You can configure webhooks to subscribe to package-related events, such as when a package is published or updated. For more information, see the "[`package` webhook event](/webhooks/event-payloads/#package)."
158158

data/release-notes/2-22/0.yml

Lines changed: 15 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -90,6 +90,19 @@ sections:
9090
9191
* [The GraphQL schema changes](https://docs.github.com/enterprise/2.22/user/graphql/overview/changelog) include backwards-compatible changes, schema previews, and upcoming breaking changes.
9292
93+
- heading: VMware Network Driver Changes
94+
notes:
95+
- |
96+
The GitHub Enterprise Server default network adapter type for VMware customers has been changed from E1000 to VMXNET3, starting with release 2.22.0. When upgrading from an earlier release to 2.22.0 or newer, if an E1000 network adapter is detected during the pre-upgrade check, the following message will be displayed at the command line:
97+
98+
```
99+
WARNING: Your virtual appliance is currently using an emulated Intel E1000 network adapter.
100+
For optimal performance, please update the virtual machine configuration on your VMware host to use the VMXNET3 driver.
101+
Proceed with installation? [y/N]
102+
```
103+
104+
The administrator can choose to update the network adapter type to VMXNET3 either before or after the GitHub Enterprise Server upgrade. The virtual appliance will need to be shutdown for this change. Customers should follow the VMware recommended steps for [changing the virtual machine network adapter configuration](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.vm_admin.doc/GUID-3719A0BE-4B4A-44FF-8A21-290950918FBD.html) to VMXNET3. Please note that `VMXNET3` will not be an option if the OS version for the virtual appliance is set to `Other Linux (64-bit)`. In that case, the OS version would first need to be changed from `Other Linux (64-bit)` to `Other 2.6.x Linux (64-bit)` or if available, `Debian GNU/Linux 9` . We recommend testing these changes on a [staging instance](https://docs.github.com/en/enterprise-server@2.22/admin/installation/setting-up-a-staging-instance) before it is performed on a production GitHub Enterprise Server. {% comment %} https://github.com/github/ghes-infrastructure/issues/781 {% endcomment %}
105+
93106
bugs:
94107
- The stafftools page for viewing pending collaborator showed a `500 Internal Server Error` when there was a pending email invite. {% comment %} https://github.com/github/github/pull/150836 {% endcomment %}
95108
- The Repository Health Check in stafftools could give incorrect results on busy repositories. {% comment %} https://github.com/github/github/pull/151160 {% endcomment %}
@@ -111,8 +124,8 @@ sections:
111124
notes:
112125
- GitHub no longer supports the OAuth application endpoints that contain `access_token` as a path parameter. We have introduced new endpoints that allow you to securely manage tokens for OAuth Apps by moving `access_token` to the request body. While deprecated, the endpoints are still accessible in this version. We intend to remove these endpoints on GitHub Enterprise Server 3.4. For more information, see the [deprecation announcement blog post](https://developer.github.com/changes/2020-02-14-deprecating-oauth-app-endpoint/).
113126

114-
# - type: Backup and Disaster recovery
115-
# note: GitHub Enterprise Server 2.22 requires at least [GitHub Enterprise Backup Utilities](https://github.com/github/backup-utils) 2.22.0 for [Backups and Disaster Recovery](https://help.github.com/enterprise/2.22/admin/guides/installation/backups-and-disaster-recovery/).
127+
backups:
128+
- GitHub Enterprise Server 2.22 requires at least [GitHub Enterprise Backup Utilities](https://github.com/github/backup-utils) 2.22.0 for [Backups and Disaster Recovery](https://help.github.com/enterprise/2.22/admin/guides/installation/backups-and-disaster-recovery/).
116129

117130
known_issues:
118131
- On a freshly set up GitHub Enterprise Server without any users, an attacker could create the first admin user. {% comment %} https://github.com/github/enterprise2/issues/1889 {% endcomment %}

0 commit comments

Comments
 (0)