daml/azure-pipelines.yml
Gary Verhaegen 6110d4be3a
push releases to github (#413)
Azure Pipelines has direct integration with GitHub, so we're just using
that. Releases on GitHub have to target a tag, so we also need to push
the tag as an intermediate step; we also need to include the platform
name in the artifact to avoid overwriting from different builds.

The two "GitHub release" steps depend on two Azure variables that are
not defined in the pipeline script. This may look like it should not
work, but in fact it does, because these variables are set by the
release script.

In Azure Pipelines, any build step can set variables for the next build
steps by outputting specially-formatted text to stdout. This text will
not appear in the build output displayed by Azure Pipelines, e.g.:

```
echo '##vso[task.setvariable variable=sauce]tomatoes'
```

would define the Azure variable `sauce` to have the string `tomatoes` as
its value for the next build steps.

See [0] for details.

[0]: https://docs.microsoft.com/en-us/azure/devops/pipelines/process/variables?view=azure-devops&tabs=yaml%2Cbatch#set-in-script
2019-04-12 11:30:13 +01:00

47 lines
1.0 KiB
YAML

# Azure Pipelines file, see https://aka.ms/yaml
# Enable builds on all branches
trigger:
# Build every commit as our release process relies on
# the release process being built alone.
batch: false
branches:
include:
- master
# Enable PR triggers that target the master branch
pr:
autoCancel: true # cancel previous builds on push
branches:
include:
- master
jobs:
- job: Linux
timeoutInMinutes: 360
pool:
${{ if eq(variables['System.PullRequest.IsFork'], 'true') }}:
vmImage: 'ubuntu-16.04'
${{ if eq(variables['System.PullRequest.IsFork'], 'false') }}:
name: 'linux-pool'
steps:
- template: ci/build-unix.yml
parameters:
name: linux
- job: macOS
timeoutInMinutes: 360
pool:
vmImage: 'macOS-10.13'
steps:
- template: ci/build-unix.yml
parameters:
name: macos
- job: Windows
timeoutInMinutes: 360
pool:
vmImage: 'vs2017-win2016'
steps:
- template: ci/build-windows.yml