Skip to content

Commit a7904cb

Browse files
stevenbrixstevenbrix
committed
adding status badge and signing
1 parent e13777a commit a7904cb

File tree

2 files changed

+4
-146
lines changed

2 files changed

+4
-146
lines changed

‎README.md‎

Lines changed: 2 additions & 144 deletions
Original file line numberDiff line numberDiff line change
@@ -1,145 +1,3 @@
1-
# Arcade Minimal CI Sample
1+
# Windows Presentation Framework (WPF)
22

3-
[![Build status](https://dnceng.visualstudio.com/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_apis/build/status/116?branchName=master)](https://dnceng.visualstudio.com/public/_build/latest?definitionId=116&branch=master)
4-
5-
This repository serves as an example of how to link GitHub repositories to Azure DevOps for CI and PR builds.
6-
7-
## Before You Start
8-
9-
You'll want to start by following the [Azure DevOps Onboarding](https://github.com/dotnet/arcade/blob/master/Documentation/AzureDevOps/AzureDevOpsOnboarding.md) instructions, which provide a thorough, step-by-step list of instructions for creating Azure DevOps CI builds for GitHub repos. From there, you'll find the [Azure DevOps YAML documentation](https://docs.microsoft.com/en-us/azure/devops/pipelines/get-started-yaml?view=vsts), which details the creation of Azure DevOps CI YAML files.
10-
11-
The purpose of this repository is to provide a jumping off point with an example YAML CI file that already has the basic architecture you'll want for your builds. All examples below are taken from this repository's [azure-pipelines.yml](azure-pipelines.yml).
12-
13-
## Set build triggers in your YAML
14-
15-
Documentation on setting CI triggers in YAML can be found [here](https://docs.microsoft.com/en-us/azure/devops/pipelines/build/ci-build-git?view=vsts&tabs=yaml#set-up-a-ci-trigger-for-a-topic-branch). The syntax for pull request triggers is identical, and will trigger whenever a PR is created merging into your specified branches.
16-
17-
**Note: YAML-based PR triggers are a feature currently being rolled out by Azure DevOps. Until they are completed, you must override the YAML PR trigger settings from the build definition GUI on Azure DevOps.**
18-
19-
```yaml
20-
trigger:
21-
- master
22-
23-
# Commenting out until Azure DevOps supports YAML PR triggers
24-
# pr:
25-
# - master
26-
```
27-
28-
## Base your builds on Arcade for ease of use
29-
30-
Arcade is designed to make many of the more complex tasks (such as sending telemetry) simple to do out of the box. It is therefore recommended that all builds base themselves on Arcade's `base.yml` template. Today, this can be done by copying the `eng/common` folder from Arcade into a local `eng/common` folder. In the near future, Engineering services will provide the capability to auto-update this folder via Maestro so that you don't need to manually take updates to common Arcade scripts.
31-
32-
```yaml
33-
phases:
34-
- template: /eng/common/templates/phases/base.yml
35-
parameters:
36-
...
37-
```
38-
39-
## Use the Arcade SDK for an easier build process
40-
41-
To quickstart your builds, you can use the Arcade SDK's build scripts. Clone the `eng/*` folder from this repository and copy [`Directory.Build.props`](Directory.Build.props), [`Directory.Build.targets`](Directory.Build.targets), [`global.json`](global.json), and [`NuGet.Config`](NuGet.Config) into your root directory. To use the build scripts, simply use a `script` task to run `eng\common\cibuild.cmd` on Windows or `eng/common/cibuild.sh` on a Unix-based OS.
42-
43-
```yaml
44-
# for Windows
45-
steps:
46-
- script: eng\common\cibuild.cmd
47-
-configuration $(_BuildConfig)
48-
-prepareMachine
49-
50-
# for Unix-based
51-
steps:
52-
- script: eng/common/cibuild.sh
53-
--configuration $(_BuildConfig)
54-
--prepareMachine
55-
```
56-
57-
Note: for the Unix-based scripts to work, make sure you clone rather than copy/paste while on Windows—copying and pasting will remove the `x` chmod parameter from the Unix scripts, which will build breaks when attempting to run them.
58-
59-
## Use matrices to quickly create phases for different build configurations
60-
61-
Azure DevOps supports using a **matrix** in a phase definition to quickly create several different phases on the same queue with slightly different build configurations. This is the recommended way to quickly add debug and release configuration builds.
62-
63-
```yaml
64-
- phase: Windows
65-
queue:
66-
name: Helix
67-
parallel: 99
68-
matrix:
69-
debug_configuration:
70-
_BuildConfig: Debug
71-
release_configuration:
72-
_BuildConfig: Release
73-
```
74-
75-
The variable defined in this matrix (in this case, `_BuildConfig`) can later be referenced in your build steps:
76-
77-
```yaml
78-
- task: DotNetCoreCLI@2
79-
inputs:
80-
command: 'build'
81-
projects: '**/*.csproj'
82-
arguments: '--configuration $(_BuildConfig)'
83-
```
84-
85-
## Run both CI and PR builds out of the same file
86-
87-
While this sample repository has no need to do so, there are many scenarios in which you may want to differentiate between different build triggers. The current recommendation is that all repositories have a single `azure-pipelines.yml` file which defines all of their builds (CI, PR, and internal). To do this, use YAML `{{ if }}` directives and the Azure DevOps built-in `Build.Reason` variable.
88-
89-
```yaml
90-
- ${{ if notIn(variables['Build.Reason'], 'PullRequest') }}:
91-
- task: DotNetCoreCLI@2
92-
inputs:
93-
command: 'publish'
94-
projects: 'HelloWorld/HelloWorld.csproj'
95-
publishWebProjects: false
96-
arguments: '--configuration $(_BuildConfig) --output $(build.ArtifactStagingDirectory) --framework $(targetFramework)'
97-
displayName: dotnet publish
98-
```
99-
100-
## Enabling telmetry
101-
102-
[Arcade](#base-your-builds-on-arcade-for-ease-of-use) provides the ability to send telemetry. To enable telemetry you must...
103-
104-
1. Set `enableTelemetry` to `true`
105-
106-
2. Define the `_HelixType`, `_HelixSource`, and `_HelixBuildConfig` variables
107-
108-
- `_HelixType` - This is a string that defines the type of run you are currently performing. Note that a trailing slash is required. e.g. test/functional/cli/, build/product/
109-
- `_HelixSource` - This defines information about the run in a specific format Type/repo/branch/. Note that a trailing slash is required. e.g. pr/corefx/master/, official/coreclr/master/
110-
- `_HelixBuildConfig` - The build configuration for your current build ie, Release, Debug, etc
111-
112-
3. For official builds, add an "AzureKeyVault" task reference to `HelixProdKV`
113-
114-
```YAML
115-
phases:
116-
- template: /eng/common/templates/phases/base.yml@arcade
117-
parameters:
118-
agentOs: Windows_NT
119-
name: Windows_NT
120-
enableTelemetry: true
121-
122-
variables:
123-
_HelixType: build/product
124-
_HelixBuildConfig: $(_BuildConfig)
125-
${{ if notIn(variables['Build.Reason'], 'IndividualCI', 'BatchedCI', 'PullRequest') }}:
126-
_HelixSource: official/dotnet/arcade-minimalci-sample/$(Build.SourceBranch)
127-
${{ if in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI', 'PullRequest') }}:
128-
_HelixSource: pr/dotnet/arcade-minimalci-sample/$(Build.SourceBranch)
129-
130-
steps:
131-
- ${{ if notIn(variables['Build.Reason'], 'IndividualCI', 'BatchedCI', 'PullRequest') }}:
132-
- task: AzureKeyVault@1
133-
inputs:
134-
azureSubscription: 'HelixProd_KeyVault'
135-
KeyVaultName: HelixProdKV
136-
SecretsFilter: 'HelixApiAccessToken'
137-
# conditions - https://docs.microsoft.com/en-us/azure/devops/pipelines/process/conditions?view=vsts
138-
condition: always()
139-
```
140-
141-
## Using the SignToolTask
142-
143-
Arcade provides an optimized way to sign files using MicroBuild, it is wrapped in a custom MSBuild task called [SignToolTask](https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.SignTool/src/SignToolTask.cs).
144-
145-
The Arcade SDK will automatically [find package](https://github.com/dotnet/arcade/blob/ae38bbbc25d03e1deb49b15ce88e2dd4c683e116/src/Microsoft.DotNet.Arcade.Sdk/tools/Sign.proj) files and forward them to be signed using SignToolTask. Therefore, if the only files that you care to sign are covered by the linked line above you don't have to do anything else. If not, you have options. You can specify explicit files to be signed / excluded from signing or changing the certificate / strong name to be used. For a detailed guide see the [SignTool package documentation](https://github.com/dotnet/arcade/blob/master/src/Microsoft.DotNet.SignTool/README.md).
3+
[![Build Status](https://dnceng.visualstudio.com/internal/_apis/build/status/dotnet.wpf)](https://dnceng.visualstudio.com/internal/_build/latest?definitionId=234)

‎eng/build.yml‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3,13 +3,13 @@ parameters:
33
# send telemetry
44
enableTelemetry: true
55
# install Microbuild plugin if not a public build
6-
enableMicrobuild: false
6+
enableMicrobuild: true
77
# queue YAML object - https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/yamlgettingstarted-schema.md#queue
88
queue: {}
99
# variables YAML object - https://github.com/Microsoft/vsts-agent/blob/master/docs/preview/yamlgettingstarted-schema.md#phase
1010
variables: {}
1111
# run this build as a public build, even in the internal project
12-
runAsPublic: false
12+
runAsPublic: true
1313

1414
# Common conditionals: There are a number of common conditionals that are useful. Generally these are used to decide what resources can be accessed,
1515
# or what logic should be applied based on the context the build is being run in.

0 commit comments

Comments
 (0)