| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Combined wxth XZ_OPT=9, this blew the memory capacity of CI runners.
This reverts commit a5f9c35f5831ef5108e87813a96eac62803852ab.
|
|
|
|
|
|
|
|
|
|
| |
CI builds stage1:exe:ghc-bin before the binary-dist target which
introduces some quite bad linearisation (see #22093) because we don't
build stage1 compiler in parallel with anything. Then when the
binary-dist target is started we have to build stage1:exe:ghc-pkg before
doing anything.
Fixes #22094
|
| |
|
| |
|
|
|
|
|
|
|
| |
We do not use any recursively cloned submodules, and this protects us
from flaky upstream remotes.
Fixes #22121
|
|
|
|
| |
In preparation for removal of the `make`-based build system
|
| |
|
|
|
|
|
|
|
|
|
| |
Fixes #21492
MonoidalMap is inlined and used to implement Variables, as before.
The top-level value "jobs" is reimplemented as a regular Map, since it
doesn't use the monoidal union anyway.
|
|
|
|
|
|
|
|
|
| |
This reverts commit 5765e13370634979eb6a0d9f67aa9afa797bee46.
The job was not tested before being merged and fails CI
(https://gitlab.haskell.org/ghc/ghc/-/jobs/1139392)
Ticket #22005
|
| |
|
|
|
|
|
|
|
| |
It appears that the CI refactoring carried out in
5ff690b8474c74e9c968ef31e568c1ad0fe719a1 failed to carry over some
critical configuration: setting the build/host/target platforms and
forcing use of a non-broken linker.
|
| |
|
|
|
|
|
|
|
|
|
| |
In general we want to ensure that the tested environment is as similar
as possible to the environment the user will use. In the case of Darwin,
this means we want to use the system's BSD command-line utilities, not
coreutils.
This would have caught #21974.
|
|
|
|
| |
Here we add a simple qemu-based test for cross-compilers.
|
|
|
|
| |
Begins to address #11958.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we would attempt to test hadrian bootstrapping in the
`validate` build flavour. However, `ci.sh` refuses to run validation
builds during release pipelines, resulting in job failures. Fix this by
testing bootstrapping in the `release` flavour during release pipelines.
We also attempted to record perf notes for these builds, which is
redundant work and undesirable now since we no longer build in a
consistent flavour.
|
|
|
|
|
|
|
| |
The documentation was moved in a10584e8df9b346cecf700b23187044742ce0b35
but this one occurrence was note updated.
Finally closes #21164.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
generating docs
The motiviation for this flag is to be able to produce documentation
which is suitable for uploading for hackage, ie, the cross-package links
work correctly.
There are basically three values you want to set this to:
* off - default, base_url = ../%pkg% which works for local browsing
* on - no argument , base_url = https:://hackage.haskell.org/package/%pkg%/docs - for hackage docs upload
* on - argument, for example, base_url = http://localhost:8080/package/%pkg%/docs for testing the documentation.
The `%pkg%` string is a template variable which is replaced with the
package identifier for the relevant package.
This is one step towards fixing #21749
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There were various issues with testing the stage1 compiler..
1. The wrapper was not being built
2. The wrapper was picking up the stage0 package database and trying to
load prelude from that.
3. The wrappers never worked on windows so just don't support that for
now.
Fixes #21072
|
| |
|
|
|
|
| |
This helps tracing errors which happen when building stage1
|
| |
|
|
|
|
|
|
|
|
|
| |
Due to the vageries of bash, you have to explicitly handle the failure
and exit when in a function.
This failed to exit promptly when !8247 was failing.
See #21358 for the general issue
|
| |
|
|
|
|
| |
This seems to fail on the ancient version of bash present on CentOS
|
|
|
|
|
|
|
| |
The centos docker image lacks the sphinx builder so we disable building
sphinx docs for these jobs.
Fixes #21580
|
|
|
|
|
|
|
|
| |
The release flavour is essentially the same as the perf flavour
currently but also enables `-haddock`. I have hopefully updated all the
relevant places where the `-perf` flavour was hardcoded.
Fixes #21486
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a CI job (hackage-doc-tarball) which generates the necessary
tarballs for uploading libraries and documentation to hackage. The
release script knows to download this folder and the upload script will
also upload the release to hackage as part of the release.
The `ghc_upload_libs` script is moved from ghc-utils into .gitlab/ghc_upload_libs
There are two modes, preparation and upload.
* The `prepare` mode takes a link to a bindist and creates a folder containing the
source and doc tarballs ready to upload to hackage.
* The `upload` mode takes the folder created by prepare and performs the upload to
hackage.
Fixes #21493
Related to #21512
|
|
|
|
|
|
|
| |
We still build Deb9 bindists for now due to Ubuntu 18 and Linux Mint 19
not being at EOL until April 2023 and they still need tinfo5.
Fixes #21469
|
|
|
|
|
|
| |
Both #20878 and #21196 were caused by unwanted dynamic dependencies
being introduced by boot libraries. Ensure that we catch this in CI by
attempting to run GHC in an environment with a minimal PATH.
|
|
|
|
|
|
|
|
| |
Windows binary distributions built with Hadrian have a target platform
suffix in the name of their root directory. Teach `ci.sh` about this
fact.
(cherry picked from commit df5752f39671f6d04d8cd743003469ae5eb67235)
|
|
|
|
| |
(cherry picked from commit fd08b0c91ea3cab39184f1b1b1aafcd63ce6973f)
|
|
|
|
|
|
|
|
| |
Due to #16177.
Also cleanup some code style issues.
(cherry picked from commit cc1c3861e2372f464bf9e3c9c4d4bd83f275a1a6)
|
| |
|
| |
|
|
|
|
|
|
| |
We also disable the stage1 testing which is broken.
Related to #21072
|
| |
|
|
|
|
|
|
| |
It's quite nice we can do this by mostly deleting code
Fixes #21373
|
|
|
|
|
|
|
|
|
| |
hadrian-ghci has finished
See https://docs.gitlab.com/ee/ci/yaml/#when
* always means, always run not matter what
* on_success means, run if the dependencies have built successfully
|
|
|
|
|
|
| |
This is necessary to build recent `text` commits.
Bumps Hackage index state for a hashable which builds with GHC 9.2.
|
|
|
|
| |
This makes it a bit easier to bump them.
|
|
|
|
|
|
|
| |
For reasons that remain a mystery, cabal-install seems to consistently
corrupt its cache on Windows. Disable caching for now.
Works around #21347.
|
|
|
|
|
| |
It appears that running the script directly does nothing (no info is
printed about saving the cache).
|
|
|
|
|
| |
It seems I forgot to update this to reflect the current state of
gen_ci.hs
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces a new script (.gitlab/gen_ci.hs) which generates
a yaml file (.gitlab/jobs.yaml) which contains explicit descriptions for
all the jobs we want to run. The jobs are separated into three
categories:
* validate - jobs run on every MR
* nightly - jobs run once per day on the master branch
* release - jobs for producing release artifacts
The generation script is a Haskell program which includes a DSL for
specifying the different jobs. The hope is that it's easier to reason
about the different jobs and how the variables are merged together
rather than the unclear and opaque yaml syntax. The goal is to fix
issues like #21190 once and for all..
The `.gitlab/jobs.yaml` can be generated by running the `.gitlab/generate_jobs`
script. You have to do this manually.
Another consequence of this patch is that we use hadrian for all the
validate, nightly and release builds on all platforms.
|
| |
|