Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta-ticket: Add Dockerfiles and CI scripts for integration testing of source and binary distributions and of downstream packages #29060

Open
mkoeppe opened this issue Jan 21, 2020 · 53 comments

Comments

@mkoeppe
Copy link
Member

mkoeppe commented Jan 21, 2020

Testing of source and binary distributions relies too much on manual testing by people.

We propose to set up Dockerfiles and CI scripts that document and test the expected capabilities of source and binary Sage distributions; and of downstream distribution packaging.

Testing of source trees and source distributions: (in progress)

With the important changes brought by #27330 (Meta-ticket: spkg-configure: Try to use as many system packages as possible), sage-the-distribution has become less monolithic; it now interacts in a more complex way with distribution packaging. We propose to add infrastructure for testing correct installation of sage source distributions on a variety of platforms.

  1. We collect information about distribution packages systematically and store it in on a per-SPKG basis in build/pkgs/SPKG/distros/. (Right now this information is scattered - in downstream sage distribution packagers' build scripts, trac tickets, replies to bug reports in google groups, the sage installation manual, personal knowledge...) This is part of Add debian/fedora/arch/conda package information to build/pkgs, generate Dockerfiles and installation help; add tox.ini #29053, for debian/fedora/arch/conda (with follow-up tickets tox.ini, build/bin/write-dockerfile.sh: Add gentoo linux, add more gentoo packages #29105, Add cygwin package information #29106 for other platforms).

  2. We generate well-defined test environments in the form of Dockerfiles. This makes it possible to test, on one's development computer, the correct installation of sage-the-distribution on a variety of platforms and configurations. Add debian/fedora/arch/conda package information to build/pkgs, generate Dockerfiles and installation help; add tox.ini #29053 provides build/bin/write-dockerfile.sh that generates the Dockerfile using the information in 1. The minimal configuration has just the packages that are needed for a build to succeed. The standard configuration installs all distribution packages that sage knows how to use.

  3. Running tests on many test environments is automated using tox in Add debian/fedora/arch/conda package information to build/pkgs, generate Dockerfiles and installation help; add tox.ini #29053. The top-level tox.ini file defines the test environments. Using tox's factor conditions (https://tox.readthedocs.io/en/latest/config.html#complex-factor-conditions), there is a succinct description of many test environments. For example, we can run tox -e docker-debian-stretch-minimal,docker-arch-latest-standard.

  4. Add GitHub Actions workflow for testing the build on various Linux distributions via docker; macOS with homebrew; and Windows (cygwin) #29087 automates running the tox tests for a selection of 34 platforms/configurations using a GitHub Actions workflow on every git push to a GitHub repository. An example run: https://github.com/mkoeppe/sage/actions/runs/32812271

Tickets:

Related meta-tickets:

Ideas without tickets so far:

  • Testing that it is possible to build without error when upgrading with git from some list of previous releases.
  • Test that packages can be cleanly uninstalled

Testing of the sage binary distributions: moved to #31133


Testing of downstream packaging of sage: (planning stage)


Symptoms:

CC: @vbraun @kiwifb @isuruf @dimpase @embray @saraedum @antonio-rojas @slel @sheerluck @tobiasdiez

Component: build

Keywords: ContinuousIntegration, sd111

Issue created by migration from https://trac.sagemath.org/ticket/29060

@mkoeppe mkoeppe added this to the sage-9.1 milestone Jan 21, 2020
@saraedum
Copy link
Member

Changed keywords from none to ContinuousIntegration

@saraedum
Copy link
Member

comment:1

I like the general idea of doing more CI a lot. Probably we should split this ticket up though or turn it into a meta ticket that tracks similar CI improvements such as #28457, #24854, #25262.

For this to be actually noticed by people we probably would need some integration with Trac. If I understood embray correctly, adding something like that, similar to the patchbot status, would not be difficult. (Since #28457 has been ready for a while, it might be a good first candidate for such an integration.)

I would propose to use GitLab CI for probably all the things you describe. We already have some CI setup there that has been mostly stable recently (though most people don't know about it https://gitlab.com/sagemath/dev/trac/pipelines?page=1&scope=all since it's not visible in trac yet.) I had made some experiments with macOS & Windows there that were not completely disappointing. For macOS you cannot use docker but still GitLab CI works, see e.g. #25980. Windows can be run inside docker (on Windows) but two years ago, the performance was not sufficient, see #25805. Without docker it worked fine though.

For our Linux CI needs, we can mostly use the free GitLab runners but last time we tried we could also easily get plenty of free credits on Google Cloud. For macOS & Windows, I had at some point built a PoC runner that slelievre volunteered to host; unfortunately, I never finished that project.

@mkoeppe
Copy link
Member Author

mkoeppe commented Jan 21, 2020

comment:2

Replying to @saraedum:

I like the general idea of doing more CI a lot. Probably we should split this ticket up though or turn it into a meta ticket that tracks similar CI improvements such as #28457, #24854, #25262.

For this to be actually noticed by people we probably would need some integration with Trac.

Yes, that would be nice. But it would already help if this were run at the time that betas and releases are prepared. I don't think it needs to be run on every ticket.

@mkoeppe mkoeppe changed the title Add Dockerfiles and CI scripts for integration testing of source and binary distributions and of downstream packages Meta-ticket: Add Dockerfiles and CI scripts for integration testing of source and binary distributions and of downstream packages Jan 21, 2020
@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@dimpase
Copy link
Member

dimpase commented Jan 30, 2020

comment:12

This needs a writeup to explain how all these cogs: tox, docker, github actions, etc. fit together and move.

@mkoeppe

This comment has been minimized.

@mkoeppe
Copy link
Member Author

mkoeppe commented Jan 30, 2020

comment:14

Replying to @dimpase:

This needs a writeup to explain how all these cogs: tox, docker, github actions, etc. fit together and move.

Good idea, please take a look at the revised description and let me know what needs more detail.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@dimpase
Copy link
Member

dimpase commented Feb 2, 2020

comment:19

On some branches there are also lists of <distro> packages in build/pkgs/<distro>.txt which appear to be used for some kind of bootstrapping.
What are these?

@mkoeppe
Copy link
Member Author

mkoeppe commented Feb 2, 2020

comment:20

build/pkgs/DISTRO.txt contains the minimal requirements for building sage from a source distribution
and build/pkgs/DISTRO-bootstrap.txt are the additional requirements so that ./bootstrap works.
In #29124 I propose to create pseudo-spkgs to capture these, instead, to make this a bit more uniform.

@mkoeppe
Copy link
Member Author

mkoeppe commented Feb 2, 2020

comment:21

Comments on the top of build/pkgs/debian.txt explain this.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe mkoeppe modified the milestones: sage-9.3, sage-9.4 May 10, 2021
@mkoeppe mkoeppe modified the milestones: sage-9.4, sage-9.5 Aug 10, 2021
@mkoeppe mkoeppe modified the milestones: sage-9.5, sage-9.6 Dec 18, 2021
@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe mkoeppe modified the milestones: sage-9.6, sage-9.7 May 3, 2022
@mkoeppe

This comment has been minimized.

@mkoeppe

This comment has been minimized.

@mkoeppe mkoeppe modified the milestones: sage-9.7, sage-9.8 Sep 19, 2022
@mkoeppe

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants