After the node resets this should hopefully not be necessary
anymore (we still had an issue this morning but I believe all nodes
that hit the issue also got the fix and if not, I’ll schedule a
targetted clean --expunge). I’ve also added node_modules to
.bazelignore to match the other node_modules directories.
changelog_begin
changelog_end
* Kill stale sandbox processes on macos and linux
changelog_begin
changelog_end
* Update build.sh
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* exitcodes are hard
changelog_begin
changelog_end
* Also kill stale sandboxes in compat tests
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
It should not be an issue, but I know of at least 4 people for whom
having envsubst in dev-env causes their local git to get confused and
spit out many lines of warning on each invocation. This also seems to
make git much slower.
Given that we're only using envsubst in this one place, I think it may
be worth replacing.
CHANGELOG_BEGIN
CHANGELOG_END
* Update rules_haskell
The workaround for linking against `Cffi` in the REPL has been
upstreamed in a more generalized form.
CHANGELOG_BEGIN
CHANGELOG_END
* ghcide: Use rules_haskell's hie-bios support
* Document `ghcide` Bazel integration
* Rename files to match module names
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Originally, we introduced this since it made fully cached builds
slightly faster. However, that was a long time ago. Looking at the
numbers now, things actually seem to be significantly faster without
this (possibly due to changes in how Bazel handles this). In
particular on MacOS where I’ve seen a couple of builds with < 20
minutes on CI which I did not see in quite some time without this.
changelog_begin
changelog_end
This disables the PDF docs builds on MacOS on CI (they are still built
locally by default) and removes them from the Nix closure by
introducing a separate ci-cached attribute that filters out texlive.
Since we built `nix-build nix -A tools -A cached` on CI, I’ve also
removed all the Tex stuff from tools which only means that it ends up
in PATH which nobody seems to care about.
changelog_begin
changelog_end
They can weigh close to 1GB, and the internal Azure networks are
unreliable enough that this adds up significant amounts of time to our
already slow CI pipeline (usually around a minute, but I've seen at
least one case where it took almost 28 minutes).
Given that we pretty much never look a them, 🔥.
CHANGELOG_BEGIN
CHANGELOG_END
On CI GHCi occasionally seems to get stuck on MacOS. I have no clue why that is
and I am unable to reproduce this locally. However, based on some
testing on CI this change seems to fix this and it simplifies things. The
ghci script was originally used when we still had the fat repl target
but now that we only load damlc, there is no need for this anymore.
CHANGELOG_BEGIN
CHANGELOG_END
I’ve seen a bunch of builds on MacOS that seemed to hang forever
somewhere during loading the target (during the step where ghci is
loading modules so after Bazel). I don’t quite know what is going on
there but it seems to correlate with the change in
https://github.com/digital-asset/daml/pull/3829 that further extended
the repl target. Given that the GHCi step takes several minutes by
now, even if it is successful, I think it makes sense to limit this to
damlc given that we very rarely have issues that would result in damlc
loading but the repl target not loading (and very few people use the
latter anyway).
* Get grpc from nix on unix
The one from Bazel seems to cause linking issues when trying to run
things in GHCi. I’ve spent some time trying to use rules_foreign_cc to
build gRPC using CMake but decided that for my own sanity it’s better
to not pursue that further.
* Address review comments
* Add missing module load
* Cleanup GHCI_SCRIPT
* use the correct file ending on macos
* Import is_linux
* Switch back to grpc-1.23
The newer version seems to cause issues in combination with the java libraries.
* Try to fix package_app on macos
* more debugging
* Maybe this is not necessary, we will never know
* linkers are the worst
* Remove debugging output again
* readd rpaths
* treat libdispatch specially
* remove hack
* more fooling around
* lalala
* 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
* Fix running the IDE on damlc
There were two issues:
1. Missing include paths.
2. Files where the module name does not match the file name.
I’ve fixed both and added a test that we can load the damlc Main.hs.
* Fix CPP issue with default da-ghci
The default REPL target did not exclude the //nix targets that set the
CPP language extensions.
* da-ghci -e () requires explicit target
As suggested in [1] da-ghci will by default first try to build the repl
with runfiles and if that fails fallback to no runfiles. If the user
specifies --data yes or no, then this automatism will be disabled.
[1]: https://github.com/digital-asset/daml/pull/996#issuecomment-490461209
* 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
