- May 06, 2022
-
-
-
There have been quite a few situations where jobs.yaml has been out of date. It's better to add a CI job which checks that it's right. We don't want to use a staged pipeline because it obfuscates the structure of the pipeline.
-
- May 04, 2022
-
-
(cherry picked from commit 16d6a8ff)
-
- Apr 27, 2022
-
-
-
It's quite nice we can do this by mostly deleting code Fixes #21373
-
- Apr 09, 2022
-
-
These don't depend on the contents of the tarball so we can run them straight after the fedora33 job finishes.
-
This also needs a corresponding commit to head.hackage, I also made the job explicitly depend on the fedora33 job so that it isn't blocked by a failing windows job, which causes docs-tarball to fail.
-
- Apr 06, 2022
-
-
This is necessary to build recent `text` commits. Bumps Hackage index state for a hashable which builds with GHC 9.2.
-
-
- Mar 24, 2022
-
-
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.
-
- Mar 12, 2022
-
-
As the `hlint` executable is only available in the linters image. Fixes #21146.
-
- Mar 09, 2022
-
-
Matthew Pickering authored
Each interation of saving the cache would copy the whole `cabal` store into a subfolder in the CACHE_DIR rather than copying the contents of the cabal store into the cache dir. This resulted in a cache which looked like: ``` /builds/ghc/ghc/cabal-cache/cabal/cabal/cabal/cabal/cabal/cabal/cabal/cabal/cabal/cabal/ ``` So it would get one layer deeper every CI run and take longer and longer to compress.
-
Matthew Pickering authored
-
- Mar 08, 2022
-
-
Matthew Pickering authored
CI is creaking under the pressure of too many jobs so attempt to reduce the strain by removing a couple of jobs.
-
- Mar 07, 2022
-
-
And adds a check to make sure we are not accidently settings BIN_DIST_PREP_TAR_COMP when using hadrian.
-
This is the first step in converting all the CI configs to use hadrian rather than make. (#21129) The metrics increase due to hadrian using --hyperlinked-source for haddock builds. (See #21156) ------------------------- Metric Increase: haddock.Cabal haddock.base haddock.compiler -------------------------
-
- Feb 25, 2022
-
-
Matthew Pickering authored
-
This MR moves the GHC linters into the tree, so that they can be run directly using Hadrian. * Query all files tracked by Git instead of using changed files, so that we can run the exact same linting step locally and in a merge request. * Only check that the changelogs don't contain TBA when RELEASE=YES. * Add hadrian/lint script, which runs all the linting steps. * Ensure the hlint job exits with a failure if hlint is not installed (otherwise we were ignoring the failure). Given that hlint doesn't seem to be available in CI at the moment, I've temporarily allowed failure in the hlint job. * Run all linting tests in CI using hadrian.
-
- Feb 21, 2022
-
-
This patch allows ghc and its dependencies to be built using a normal invocation of cabal-install. Each componenent which relied on generated files or additional configuration now has a Setup.hs file. There are also various fixes to the cabal files to satisfy cabal-install. There is a new hadrian command which will build a stage2 compiler and then a stage3 compiler by using cabal. ``` ./hadrian/build build-cabal ``` There is also a new CI job which tests running this command. For the 9.4 release we will upload all the dependent executables to hackage and then end users will be free to build GHC and GHC executables via cabal. There are still some unresolved questions about how to ensure soundness when loading plugins into a reinstalled GHC (#20742) which will be tighted up in due course. Fixes #19896
-
- Feb 12, 2022
-
-
The release bindists are currently a mixture of validate and release builds. This is bad because the validate builds don't have profiling libraries. The fix is to make sure there is a release job for each platform we want to produce a release for.t Fixes #21066
-
- Feb 08, 2022
-
-
- Feb 04, 2022
-
-
The main motivation for this patch is to allow tests to be added to the testsuite which test things about the source tree without needing to build GHC. In particular the notes linter can easily start failing and by integrating it into the testsuite the process of observing these changes is caught by normal validation procedures rather than having to run the linter specially. With this patch I can run ``` ./hadrian/build test --flavour=devel2 --only="uniques" ``` In a clean tree to run the checkUniques linter without having to build GHC. Fixes #21029
-
- Feb 03, 2022
-
-
Fixes #21002
-
- Jan 27, 2022
-
-
In recent releases a libnuma dependency has snuck into our bindists because the images have started to contain libnuma. We now explicitly pass `--disable-numa` to configure unless explicitly told not to by using the `ENABLE_NUMA` environment variable. So this is tested, there is one random validate job which builds with --enable-numa so that the code in the RTS is still built. Fixes #20957 and #15444
-
-
- Jan 25, 2022
-
-
deb9 is now end-of-life so we are dropping support for producing bindists.
-
- Jan 12, 2022
-
-
This fixes serious skew in the performance numbers because the packages were build with core-lint. Fixes #20826
-
-
- Dec 12, 2021
-
-
Annoyingly, this will require downstream changes in head.hackage, which depends upon the artifact produced by this job. Prompted by !6462.
-
- Dec 01, 2021
-
-
A manual job for testing the non-tables-next-to-code configuration.
-
- Nov 25, 2021
- Nov 23, 2021
-
-
Ben Gamari authored
-
- Nov 19, 2021
-
-
It appears that Darwin's toolchain includes system headers in the dependency makefiles it generates with `-M` with older `MACOSX_DEPLOYMENT_TARGETS`. To avoid this we have bumped the deployment target for x86-64/Darwin to 10.10.
-
- Nov 16, 2021
-
-
Reduce a bit of duplication and a manual step when running builds manually.
-
This makes it easier to invoke ci.sh on Darwin by teaching it to manage the nix business.
-
- Nov 13, 2021
-
-
