Stream: Coq devs & plugin devs

Topic: Coq Platform Windows CI broken cause SF changed its URLs


view this post on Zulip Michael Soegtrop (Sep 16 2021 at 09:40):

For the CI managers: Coq Platform Windows CI is broken since last night cause sourceforge (from where we download NSIS) changed its download URLs. A fix is on the way.

view this post on Zulip Michael Soegtrop (Sep 16 2021 at 09:57):

Which reminds me that one day we wanted to have an INRIA file sever for all the files we need for CI ...

view this post on Zulip Michael Soegtrop (Sep 16 2021 at 15:46):

I fixed it on 2021.02 branch and merged it over to the dev-ci branch, so it should work again.

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 07:50):

@Emilio Jesús Gallego Arias @Théo Zimmermann : the new download location of NSIS from sourceforge is not terribly reliable (it failed in one of my daily CI runs despite 20 retires). Can we please have some INRIA file server, where we host such files - I would host Cygwin there as well then. As discussed it would be desirable to switch Cygwin only at certain intervals and just keep ony daily build with latest cygwin to tay informed.

view this post on Zulip Théo Zimmermann (Sep 17 2021 at 08:57):

If these are just tarballs that need to be stored, a quicker way to set things up would be to use a dedicated GitHub repository with tarballs attached to releases. We could even automate the update process by creating new releases e.g. every week, with a GitHub Action.

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 09:25):

@Théo Zimmermann : I am not so sure if this would work nicely - for cygwin it would be a few 100 tarballs, but of course one could make a tarball of tarballs ...

FYI: cygwin is about 1GB and 1000 files (but this includes some history - I just lookd at my local cache folder)

view this post on Zulip Théo Zimmermann (Sep 17 2021 at 09:26):

OK, then a dedicated server is probably better. I have no idea how this can be set up though.

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 10:04):

Maybe @Maxime Dénès has an idea?

Should we use your GitHub idea in the meanwhile? Maybe call it coq/prerequisites?

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 10:04):

For NSIS this would work nicely.

view this post on Zulip Théo Zimmermann (Sep 17 2021 at 12:38):

Yes, we can do that and use it only for the pieces where it is reasonable.

view this post on Zulip Théo Zimmermann (Sep 17 2021 at 12:39):

I can create the repo and make you an admin if you want to go ahead.

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 13:40):

@Théo Zimmermann : yes, please go ahead.

So the git part of the repo just contains a readme file and we put the files into releases - possibly named after Coq Platform releases?

view this post on Zulip Théo Zimmermann (Sep 17 2021 at 13:41):

Yes. BTW, this could be used to enhance reproducibility as users would not necessarily get the latest version of the dependencies which are not pinned to a particular version but would be ensured to get one that works.

view this post on Zulip Théo Zimmermann (Sep 17 2021 at 13:44):

Done.

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 13:53):

Perfect, thanks - I will try it with NSIS right away

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 14:08):

PR CI is running ...

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 14:08):

Suggestions on what else should go there are welcome.

view this post on Zulip Michael Soegtrop (Sep 17 2021 at 14:12):

Your comment on reproducability mostly concerns opam and cygwin. All the rest (NSIS for that matter) uses fixed versions. I will double check how large cygwin really is - if it is 500MB, it might be feasible to host it that way as well.

view this post on Zulip Théo Zimmermann (Sep 17 2021 at 14:34):

We can add more when we feel the need. For instance, in the past, the source location of ocamlfind was frequently unreliable.


Last updated: Oct 21 2021 at 19:03 UTC