CI infrastructure missing

[embray]

I did have a cygwin build machine but at some point I couldn't access it anymore and had to take it down. I think it might have actually been hijacked, being that it was a Windows machine exposed to the internet, and a weak admin password :)

I'm trying to get it up and running again but last time I tried I ran into some problems. I need to go into my office at some point because some of the infrastructure stuff is on my local disk and not checked into the repo, oops :upside_down_face:

[mkoeppe]

When you have a little bit of time to work on Sage for Cygwin, there are a number of tickets that need some expert help. In particular https://trac.sagemath.org/ticket/29537

[embray]

I had no idea you were doing so much work with automated builds using github actions. It's impressive, but I have no idea how any of it works. I wish I had known or I might have tried to prevent some wheel-reinventing. My build scripts already work very well, but I didn't know GitHub Actions could be used for Windows builds, much less using Cygwin.

I would much rather be relying on GitLab for this rather than have our CI spread out all over the place, but the challenge there has been maintaining functional Windows build runners. As I've said before I used to have some but they keep crapping out on me.

I don't know what to say about the issue you linked to except that it's clear either SAGE_FAT_BINARY is not being applied, or there is a problem with the current spkg for NTL (I don't know if it's been updated lately). But that wouldn't be the first time.

[embray]

At some point you'll have to walk me through how this works and what it's doing. I'm pretty confused.

If you look at my Makefile it's only about 250 lines long (and while aspects of it are confusing it's fairly straightforward). I don't know why even ci-cygwin-minimal.yml is so long and involves so many stages and sub-stages. There also does appear to be an awful lot of repetition though. Since this is a YAML file does it support templating and anchors like .gitlab-ci.yml does?

[mkoeppe]

I had no idea you were doing so much work with automated builds using github actions. It's impressive, but I have no idea how any of it works. I wish I had known or I might have tried to prevent some wheel-reinventing. My build scripts already work very well, but I didn't know GitHub Actions could be used for Windows builds, much less using Cygwin.

I would much rather be relying on GitLab for this rather than have our CI spread out all over the place, but the challenge there has been maintaining functional Windows build runners. As I've said before I used to have some but they keep crapping out on me.

The GitHub Actions build is very convenient exactly because one does not need to maintain runners.

However, it comes with a limitation: We get 6 hours on a 2-core virtual machine per job. This is enough for building and testing Sage on Linux or Mac, but the Cygwin build is much too slow for it.

All of the complexity of ci-cygwin-*.yml ("minimal", by the way, just refers to the set of Cygwin packages that is installed) comes from breaking the build into <= 6 hour chunks, some of which can run in parallel. It saves and loads the contents of $SAGE_LOCAL via build artifacts.

The yml file is the result of copy paste. https://trac.sagemath.org/ticket/29650 outlines some possible improvements -- it should really be generated by a script. I am not aware of templating features within the YAML file.

[embray]

Thanks, I understand a better now, in particular why it's broken into so many pieces. I'm really impressed! We could probably also add building the installer release to this. Building the installer is mostly a matter of

1) Create a fresh Cygwin install with only the runtime requirements installed (although in practice this includes many of the build requirements as well)

2) Copy the built SAGE_LOCAL into it (along with some cleanup of unneeded build files and stripping binaries, rebasing, etc.)

3) Run InnoSetup with the existing SageMath.iss script (my Makefile shows how to do this).

[embray]

In .gitlab-ci.yml you can do something like:

.build-job: &build_template
    script:
        - do something with ${VARIABLE}

build-stage-i-a:
    variables:
        VARIABLE: foo
    <<: *build_template

In other words, you can template some common features of a job, and that use that template in multiple jobs, interpolated over different variable definitions or other minor variations.

[mkoeppe]

This looks great, but I'm not aware of a similar feature on GH Actions.

[mkoeppe]

We could probably also add building the installer release to this. Building the installer is mostly a matter of

1. Create a fresh Cygwin install with only the runtime requirements installed (although in practice this includes many of the build requirements as well)

Perhaps this distinction of build time / run time is not so important?

2. Copy the built SAGE_LOCAL into it (along with some cleanup of unneeded build files and stripping binaries, rebasing, etc.)
3. Run InnoSetup with the existing SageMath.iss script (my Makefile shows how to do this).

Good idea. I think you have already upstreamed most of the complicated bits of sage-windows. It would be great if the remaining bits, could just be integrated into sage as well.

Do you have time to work on it? I'll be happy to help (with all the things I figured out about GH Actions by experimenting) but it would be best if you could take the lead.

[mkoeppe]

I have created https://trac.sagemath.org/ticket/30023 for this

[embray]

I hope to have more time to work on this soon. Bogged down with other things though. In the meantime I'll continue making Sage for Windows with my existing build scripts / workflow. But it it would be great to merge the two, and take the best pieces from both worlds (though what you've already done should be the baseline I think).