mirror of
https://github.com/commercialhaskell/stackage.git
synced 2026-01-11 23:08:30 +01:00
New local curator check & instructions
This commit is contained in:
parent
821c342f26
commit
5641a69e2b
3
.gitignore
vendored
3
.gitignore
vendored
@ -5,3 +5,6 @@ lts-*.yaml
|
||||
*.swp
|
||||
check-plan.yaml
|
||||
*~
|
||||
/constraints.yaml
|
||||
/snapshot.yaml
|
||||
/snapshot-incomplete.yaml
|
||||
|
||||
24
CURATORS.md
24
CURATORS.md
@ -18,8 +18,8 @@ This section sketches out at a high level how the entire Stackage build/curation
|
||||
process works:
|
||||
|
||||
* [build-constraints.yaml](https://github.com/commercialhaskell/stackage/blob/master/build-constraints.yaml) specifies packages to be included in Stackage
|
||||
* [stackage-curator](http://www.stackage.org/package/stackage-curator) combines build-constraints.yaml with the current state of Hackage to create a build plan for a Stackage Nightly
|
||||
* stackage-curator can check that build plan to ensure all version bounds are consistent
|
||||
* [curator](https://github.com/commercialhaskell/stack/tree/master/subs/curator) combines build-constraints.yaml with the current state of Hackage to create a build plan for a Stackage Nightly
|
||||
* `curator` can check that build plan to ensure all version bounds are consistent
|
||||
* The [Travis job](https://github.com/commercialhaskell/stackage/blob/master/.travis.yml) performs these two steps to provide immediate feedback on pull requests
|
||||
* Docker Hub [builds](https://github.com/commercialhaskell/stackage/blob/master/Dockerfile) a [Docker image](https://hub.docker.com/r/commercialhaskell/stackage/) for running builds
|
||||
* The stackage-build server (described below) is able to run automated builds using the [build.sh script](https://github.com/commercialhaskell/stackage/blob/master/automated/build.sh)
|
||||
@ -72,7 +72,7 @@ Most common technique, just prevent a new version of a library from
|
||||
being included immediately. This also applies to when only benchmarks
|
||||
and tests are affected.
|
||||
|
||||
* Copy the stackage-curator output and create a new issue, see e.g
|
||||
* Copy the `curator` output and create a new issue, see e.g
|
||||
https://github.com/commercialhaskell/stackage/issues/2108
|
||||
|
||||
* Add a new entry under the "stackage upper bounds" section of `build-constraints.yaml`. For the above example it would be
|
||||
@ -84,7 +84,7 @@ https://github.com/commercialhaskell/stackage/issues/2108
|
||||
```
|
||||
|
||||
* Commit (message e.g. "Upper bound for #2108")
|
||||
* Optionally: Verify with `stackage-curator check` locally
|
||||
* Optionally: Verify with `./check` locally
|
||||
* Push
|
||||
* Verify that everything works on the build server (you can restart the build or wait for it to to run again)
|
||||
|
||||
@ -110,7 +110,7 @@ new package may appear if its dependencies were part of this issue but
|
||||
have been updated since the last time we checked. We want to give
|
||||
these new packages ample time to be upgraded.
|
||||
|
||||
If stackage-curator is happy commit the change ("Remove upper bounds
|
||||
If `curator` is happy commit the change ("Remove upper bounds
|
||||
and close #X"). After doing this the next nightly build may fail
|
||||
because some packages didn't have an upper bound in place, but
|
||||
compilation failed. In this case revert the previous commit so any
|
||||
@ -367,30 +367,30 @@ We do not run the full stackage build locally as that might take too
|
||||
much time. However, some steps on the other hand are much faster to do
|
||||
yourself, e.g. verifying constraints without building anything.
|
||||
|
||||
To get started, install `stackage-curator` via Git, or [the Linux binary]:
|
||||
To get started, install `curator` via Git:
|
||||
|
||||
```
|
||||
$ git clone git@github.com:fpco/stackage-curator.git
|
||||
$ cd stackage-curator && stack install
|
||||
$ git clone git@github.com:commercialhaskell/stack.git
|
||||
$ cd stack && stack install curator
|
||||
```
|
||||
|
||||
It is a good idea to upgrade `stackage-curator` at the start of your week.
|
||||
It is a good idea to upgrade `curator` at the start of your week.
|
||||
Then, clone the stackage repo, get the latest packages and run dependency
|
||||
resolution:
|
||||
|
||||
```
|
||||
$ git clone git@github.com:commercialhaskell/stackage.git
|
||||
$ stack update && stackage-curator check
|
||||
$ cd stackage
|
||||
$ ./check
|
||||
```
|
||||
|
||||
This can be used to make sure all version bounds are in place, including for
|
||||
test suites and benchmarks, to check whether bounds can be lifted, and to get
|
||||
[tell-me-when-its-released] notifications.
|
||||
|
||||
`stackage-curator` does not build anything, so you wont see any compilation
|
||||
`curator` does not build anything, so you wont see any compilation
|
||||
errors for builds, tests and benchmarks.
|
||||
|
||||
[the Linux binary]: https://s3.amazonaws.com/stackage-travis/stackage-curator/stackage-curator.bz2
|
||||
[tell-me-when-its-released]: https://github.com/commercialhaskell/stackage/blob/master/CURATORS.md#waiting-for-new-releases
|
||||
|
||||
## Adding new curators
|
||||
|
||||
12
check
12
check
@ -1,6 +1,14 @@
|
||||
#!/bin/sh
|
||||
#!/bin/bash
|
||||
|
||||
# Convenience script for checking constraints locally
|
||||
|
||||
cd `dirname $0`
|
||||
exec stack exec --resolver ghc-8.6.5 stackage-curator check
|
||||
|
||||
export GHCVER=$(sed -n "s/^ghc-version: \"\(.*\)\"/\1/p" "build-constraints.yaml")
|
||||
|
||||
NIGHTLY="nightly-$(date +%Y-%m-%d)"
|
||||
curator update &&
|
||||
curator constraints --target=$NIGHTLY &&
|
||||
curator snapshot-incomplete &&
|
||||
curator snapshot &&
|
||||
stack --resolver ghc-$GHCVER exec curator check-snapshot
|
||||
|
||||
Loading…
Reference in New Issue
Block a user