This is in preparation for #2326 as well as for splitting hie-core
into a separate repo. Given that, it explicitely avoids using our
dev-env.
We do need to install a few system packages, so for now this uses the
hosted builder so we can do this. Another option would be to just add
those to our builders. I don’t really have a preference either
way. The builds are < 5 minutes so I don’t expect issues from using
the hosted builders.
- change jobs names to match the names Azure uses, so GitHub doesn't get
confused. These were the names when the pipeline was originally set
up; since I changed them it looks like Azure and GitHub don't agree on
test names, resulting in some occurrences of GitHub forever expecting
more info about `linux` while `Linux` is completed.
- add `-i` to cURL invocations, so we can see the response headers. This
is an attempt to debug a situation I have seen three times now where
Azure says it executed the cURL step successfully, yet no message
appears in Slack.
- add test name to failure message sent to Slack.
* Fix termination of scenario service on Windows
The lack of a proper Windows IO manager resulted in us being unable to
kill the conduits reading the output of the scenario service so `damlc
test` and `damlc ide` blocked forever. This PR fixes the problem by
shutting down the scenario service (by closing its stdin) before
killing the conduits .
* Use fail instead of error
* Add debugging output
* Remove debug output
* Bump timeout of perf test
* ci: always use the linux-pool
reduce the difference of environment between external and internal
contributions
* infra: tweak the linux cache warmup script
Don't share the same bazel cache directory with the disk cache, which is
something else. Be more specific about the target. Clean after yourself.
* infra: bump the linux agent disk to 200GB
avoid running out of disk space
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
* nix: add the more providers to terraform
* docs: make tarballs more reproducible
* ci: use the linux-pool pool
* ci: tweak the nix installation
handle the case where the user is root and on ubuntu
* infra: terraform fmt
* infra: add Azure Pipeline agents
* ci: only enable linux-pool for internal PRs
