Nightly builds roadmap - Githubissues

Zimmi48 commented 6 years ago

Providing nightly Coq builds would simply mean having a webpage where users can download a binary package corresponding to the latest version of Coq master branch. This should include at least the packages we provide now for released versions (MacOS, Windows 32 bits and Windows 64 bits) but it would be cool to provide more (e.g. a Debian / Ubuntu .deb binary package, a Nix package with a binary cache, etc).

Nightly builds are useful to ensure that all our users have the possibility of testing development (alpha) versions, including those who are on platforms where compiling Coq from sources is harder. In particular, developers of Coq packages we test in CI must be able to run their packages with the latest version of Coq master. Additionally, providing a pre-compiled Linux package (.deb or Nix) would help gain build time for people testing their package on CI with the development version of Coq.

We are already quite close to providing nightly builds. Here are the steps I see:

[x] Build MacOS and Windows packages on CI.
[x] (optional) Build Linux binary packages on CI (done with Nix).
[x] Give a precise version number to these packages. See coq/coq#483. What is the current status of this PR? @ejgallego do you intend to take care of finishing it and do you think that Dune is going to help here?
[x] Choose where to host these packages. Because Travis doesn't provide native build artifact support, the MacOS package currently uses bintray. With a proper version number, it would make sense to use this platform for nightly builds and we could upload Windows package over there as well.

ejgallego commented 3 years ago

We also have the docker images which are "nightly" , and which I think are the most useful to end users (along with the Nix setup) for the "nightly build use case", which is usually running CI or other kind of testing daily.

JasonGross commented 3 years ago

Would it make sense to provide snap packages for nightly builds which would be useful for CI users who want to make use of multiple GH Actions (docker-based GitHub actions are not composable/modular)?

Zimmi48 commented 3 years ago

The Snap packages are already built nightly (although this is only for the stable release as clarified by Michael but this should be also for the dev version in the future). Are you talking about uploading these nightly Snap packages to the Snap store? I have no idea how practical it would be.

erikmd commented 3 years ago

Hi @ejgallego, hi all

We also have the docker images which are "nightly" , and which I think are the most useful to end users (along with the Nix setup) for the "nightly build use case", which is usually running CI or other kind of testing daily.

indeed, but just to clarify: the coqorg/coq:dev, mathcomp/mathcomp and mathcomp/mathcomp-dev are not nightly anymore: as soon as a PR is merged in coq master, these docker images are sequentially rebuilt :-)

erikmd commented 3 years ago

− and just FTR, the documentation in coq-community is up-to-date regarding that aspect:

JasonGross commented 3 years ago

Are you talking about uploading these nightly Snap packages to the Snap store? I have no idea how practical it would be.

I'm not sure about the technical issues here, but my wish is for a solution to https://github.com/coq-community/docker-coq-action/issues/51 where I can have a GitHub action that "installs" Coq rather than having it run my script in a container that includes Coq. I was thinking that snap might be a solution to this, though it looks like there's also some discussion at https://github.com/coq-community/templates/issues/69 about basing things on nix rather than snap?

erikmd commented 3 years ago

Hi @JasonGross :) could you give a bit more details on your main requirement?

would the ability (e.g. using Nix) to install any version of any software in a GHA container be enough?

(BTW this could have the upside to have a script and environment fully reproducible outside of GHA's CI, and thereby compatible with other CI platforms, and with a local execution)
otherwise would a GHA, named e.g. setup-coq-opam, installing (outside any container) an opam switch with the desired version of Coq etc. would fit your use case?

(I'll have little time to work on this in April but I had suggested a possible approach in https://github.com/coq-community/docker-coq-action/issues/51#issuecomment-772748810 → so if you think it's worth it, we could experiment this further)
if the answer to the item 2 is yes, would it be enough if this tooling was dedicated to GNU/Linux GitHub Actions workers? (as an existing opam switch would definitely be incompatible with a Windows OS :)

JasonGross commented 3 years ago

I suppose (1) would probably be enough, though I'd have to figure out the relevant syntax for installing the right version of Haskell, Cabal, Python, etc

(2), copying over an existing opam switch for whatever version of Linux there is, sounds pretty great, assuming it works!

(Tangentially: Note, btw, that https://github.com/avsm/setup-ocaml/ works with Windows and I have just managed to get a script working that is basically the same between Windows and Linux/Mac actions at https://github.com/mit-plv/fiat-crypto/pull/966 which tests the opam package of fiat-crypto.)

MSoegtropIMC commented 2 years ago

I wanted to follow up on this issue and ask what the final conclusion / request is.

Possible are:

run the .dev pick in daily CI on selected or all platforms
create a new .ci pick which takes the versions from Coq CI for those packages shared between Coq CI and Platform on selected or all platforms

In order to avoid confusion with CI status, I would probably run these as separate actions.

Zimmi48 commented 2 years ago

I think that for Coq master, using the .dev picks or the CI picks would be pretty close because both of them are usually tracking the main development branches and are aimed to keep building with Coq dev.

MSoegtropIMC commented 2 years ago

Indeed I had a look at (https://github.com/coq/coq/blob/master/dev/ci/ci-basic-overlay.sh) and it seems to be 100% on master - afair it was not always like this.

So I guess we can drop the idea of a separate CI pick.

The remaining question then is for which platforms such a nightly build should be done. All?

Zimmi48 commented 2 years ago

It was always close to this state. This is not the case when using a v8.X branch. (Then reusing the CI pick makes sense.)

The remaining question then is for which platforms such a nightly build should be done. All?

If it is easy to generate and make the installers downloadable, then probably yes. That being said, since the nightly builds are not for beginners, and that the experienced users should probably prefer the Platform scripts, providing the .dev pick through the scripts only would probably also be fine.

MSoegtropIMC commented 2 years ago

It is easy to do this, but it costs quite a bit of server time (5..6h per platform) and in the end roughly 100..200 kg CO2 per year (assuming the German energy mix).

I would then suggest that I just reenable the dev build in CI, so that I know when it gets broken.

Zimmi48 commented 2 years ago

Agreed that it's probably not worth. Let's just make sure that we document somewhere that this dev build is available and tested.

MSoegtropIMC commented 2 years ago

Doing this I probably also should put the older builds into a weekly build. They don't break regularly, but they do break (e.g. I recently did a patch to OCamlfind where I used library functions introduced in OCaml 4.13, which broke the older Coq versions since they picked up this patch).

MSoegtropIMC commented 4 months ago

Triaging note: this is mostly done - the main issue is the signing of the installers, which INRIA is still working on.

coq / platform

Nightly builds roadmap #108