-
-
Notifications
You must be signed in to change notification settings - Fork 479
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
Comments
Changed keywords from none to ContinuousIntegration |
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. |
comment:2
Replying to @saraedum:
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. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:12
This needs a writeup to explain how all these cogs: tox, docker, github actions, etc. fit together and move. |
This comment has been minimized.
This comment has been minimized.
comment:14
Replying to @dimpase:
Good idea, please take a look at the revised description and let me know what needs more detail. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:19
On some branches there are also lists of |
comment:20
|
comment:21
Comments on the top of |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:41
Hoping we can make progress on this ticket this week - https://wiki.sagemath.org/days111 |
Changed keywords from ContinuousIntegration to ContinuousIntegration, sd111 |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:44
Moving to 9.4, as 9.3 has been released. |
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.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).We generate well-defined test environments in the form of
Dockerfile
s. 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 providesbuild/bin/write-dockerfile.sh
that generates theDockerfile
using the information in 1. Theminimal
configuration has just the packages that are needed for a build to succeed. Thestandard
configuration installs all distribution packages that sage knows how to use.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. Usingtox
'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 runtox -e docker-debian-stretch-minimal,docker-arch-latest-standard
.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 everygit push
to a GitHub repository. An example run: https://github.com/mkoeppe/sage/actions/runs/32812271Tickets:
spkg-configure.m4
scripts work as expected.github/workflows/
: Test all optional packages, add workflow for testing all experimental packageslocal-sudo-ubuntu-standard
, etc.conda-forge
tests brokentox.ini
, GH Actions: Update Linux platformstox.ini
: Addcentos-stream-8
,centos-stream-9
, remove defunctcentos-6
-recommended
package factortox.ini
: Linux platform updatestox
/ GH Actions: Addcentos-7-devtoolset-gcc_{9,10,11}
ppa:ubuntu-toolchain-r
make build-local
first, cache image for jobmake build
ci-cygwin*.yml
: Fix packaging up of SAGE_LOCAL/var/tmp/sage/build/*configure --enable-editable
tox -e docker-...-incremental
tox.ini
for homebrewtox.ini
, GH Actions: Update macOS environmentsSAGE_ROOT/tox.ini
: Add variants that provision a system python usingpyenv
wsl
as a technology, to complementlocal
anddocker
#30505: tox.ini: Addwsl
as a technology, to complementlocal
anddocker
cygwin
as a technology, to complementlocal
anddocker
#30924: tox.ini: Addcygwin
as a technology, to complementlocal
anddocker
ci-sage.yml
(suggested in Add integration testing with python from Debian, Ubuntu, Fedora, Gentoo, Arch Linux, OpenSUSE, Slackware pypa/setuptools#2923 (comment))Related meta-tickets:
tox.ini
,build/bin/write_dockerfile.sh
Ideas without tickets so far:
Testing of the sage binary distributions: moved to #31133
Testing of downstream packaging of sage: (planning stage)
sage -c SAGECOMMAND
,sage -t
,sage -python -c COMMAND
, ... work with thesage
script provided by the distribution (see https://groups.google.com/d/msg/sage-packaging/BmkxIBdwbvE/fRMl2sjdBQAJ)devcontainer.json
for development with VS Code in a Docker containerSymptoms:
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
The text was updated successfully, but these errors were encountered: