Hi Herbert,
Last week I did some work to clean up and document GHC's head.hackage
infrastructure. At this point we have a full CI pipeline, including
automatic deployment of a Hackage repository.
I asked on #ghc and there was quite some appetite to use
gitlab.haskell.org:ghc/head.hackage as the h
Ben Gamari writes:
> Hi Herbert,
>
> Last week I did some work to clean up and document GHC's head.hackage
> infrastructure. At this point we have a full CI pipeline, including
> automatic deployment of a Hackage repository.
>
> I asked on #ghc and there was quite some appetite to use
> gitlab.ha
Count me among the people who are eagerly awaiting this move. If I
understood Ben correctly when discussing this idea with him on #ghc, then
one of the benefits of having head.hackage on GitLab would be that the
head.hackage index would automatically regenerate any time a commit lands.
This would m
Ryan Scott writes:
> Count me among the people who are eagerly awaiting this move. If I
> understood Ben correctly when discussing this idea with him on #ghc, then
> one of the benefits of having head.hackage on GitLab would be that the
> head.hackage index would automatically regenerate any time
Ben Gamari writes:
> Hi Herbert,
>
> Last week I did some work to clean up and document GHC's head.hackage
> infrastructure. At this point we have a full CI pipeline, including
> automatic deployment of a Hackage repository.
>
> I asked on #ghc and there was quite some appetite to use
> gitlab.ha
Ben Gamari writes:
> Hi Herbert,
>
> Last week I did some work to clean up and document GHC's head.hackage
> infrastructure. At this point we have a full CI pipeline, including
> automatic deployment of a Hackage repository.
>
> I asked on #ghc and there was quite some appetite to use
> gitlab.ha
