There was an issue where multiline commit messages were not encoded at
all, yielding invalid JSON. This should fix it. This commit message is
designed to test it before it gets to master.
$(exit 1)
`exit 1`
end quote: "
invalid json input
* Rename hie-core to ghcide
The name `hie-core` has caused a lot of confusion as to how we relate
to haskell-ide-engine so changing it should hopefully help with that.
I also think that ghcide is still a good name once we hopefully
integrate with haskell-ide-engine more closely.
The name ghcide seems to have a reasonable amount of support on
Twitter https://twitter.com/ndm_haskell/status/1170681262987710464
which is of course the only good way to come up with names.
* Add a readme that points people to the new directory.
* Fix bogus replacements
* Use a proper link
* links are hard
At the moment, if we try to run the build of a release commit after it
has succeeded, the `git tag` step fails. We do not normally try to
rebuild old commits that had succeeded, but sometimes Azure gets
confused when we ask for rerunning specific jobs within a build, and
reruns the whole build.
This creates two (small, bubt annoying) problems:
1. It adds noise to the #team-daml channel as it notifies of the build
failure, and
2. It marks the commit as failed with a red cross on the github list of
commits, which obviously doesn't look great for release commits.
This fixes that. Note that if a release does fail after the `git tag`
step (e.g. some network error between Azure and GitHub), this **does
not** change the necessary steps to remediate, as that situation would
already be broken in the current setup. (Steps to remediate would
essentially boil down to deleting the tag on GitHub before rerunning so
the build can create it again.)
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
