-
Notifications
You must be signed in to change notification settings - Fork 198
Bikeshed: build client extensions
The build bot keeps a list of failed package versions, so it doesn't keep building them over and over again.
However, just because a version fails now doesn't mean it will continue to fail in the future. Cases include:
-
Candidates. Unlike in the main namespace, users can overwrite existing candidate versions. See https://github.com/haskell/hackage-server/issues/69.
-
Changed metadata. Users can modify the bounds of existing packages so that a past dependency failure may no longer apply.
-
New packages. Similarly, a maintainer may accidentally upload a package before releasing one of its dependencies. Any builds in the intervening period will fail, but builds afterward may succeed.
TODO
Fortunately, Hackage already records the upload time for every package hosted on the server. We can retrieve this timestamp by invoking HEAD or GET on the tarball:
$ curl -I http://hackage.haskell.org/package/hello-1.0/hello-1.0.tar.gz
HTTP/1.1 200 OK
Server: nginx/1.6.0
Date: Sun, 07 Sep 2014 23:37:47 GMT
Content-Type: application/x-gzip
Connection: keep-alive
Content-MD5: e7ce8159f41989fbce0ce79f6aba156c
ETag: "e7ce8159f41989fbce0ce79f6aba156c"
Last-modified: Fri, 02 Jul 2010 14:29:29 GMT <--
Modify the list of failed packages to store a "last modified" field along with the package ID.
Then modify the build client to download packages itself, rather than going through Cabal.
In the failed list, store a "last modified" date along with the package version.
-
How does metadata editing come into this?
-
This depends on Cabal PR 2025, which hasn't been released yet. Is it okay telling users to build Cabal from master?