stan-dev / httpstan-wheels Goto Github PK

There have been a 3 week pause in actions schedule. Has something turned the workflow off?

Travis CI ended its free tier.

Here's an example of a project using multibuild (like we do) switching from travis-ci to github actions, python-pillow/pillow-wheels#169

The switch should initially be done in https://github.com/stan-dev/httpstan-wheels, not in this repository.

This can be done after 4.1.0 is released.

Linux wheels are not tested. Testing linux wheels was removed in commit 8a10103

Linux wheels are working fine on Ubuntu 20.04. They do not work on Ubuntu 18.04. There is no way to use multibuild to test the wheels on Ubuntu 20.04.

Right now we are assuming that if the wheels pass tests on macOS they will also pass tests on Ubuntu 20.04.

Looking at the build log it seems like Python 3.9 is not available on travis. But multibuild suggests it is available.

Travis-ci.org seems utterly broken on this repository specifically. I started the process of migration to travis-ci.com (which travis-ci is encouraging, labeling travis-ci.org as "legacy"). This may not have been wise but there was little choice since nothing was working -- and we have no other way of making macOS wheels.

We still need a Stan org owner to sign up for the migration beta option here: https://travis-ci.com/organizations/stan-dev/migrate It looks like we could just migrate this one repository and leave everything else as is. /cc @bgoodri @syclik

I'm inclined to switch everything over to GitHub Actions or Azure Pipelines because I have the sense that they are faster and because it would be nice to do all builds (linux, macos, win) in a single place. But the tool we use here (multibuild) is currently bound to travis. So if we want to release macos binaries we need to use it for the moment. And we do want to release macos binaries.

As for the travis-ci.org problem, it seems like others have been having this problem. There also have been outages that travis-ci reports, e.g., https://www.traviscistatus.com/incidents/rx6fhs3wqcln

edit: add link to outage report

This may be due to some change in poetry or pip

the macOS builds are failing due to the lack of numpy wheels for Python 3.9

In general, we should not even try releasing wheels for Python 3.x until numpy has already released wheels for Python 3.x. It would be nice to be able to automate this so we do not waste time.

The travis build is timing out on the call to delocate. We likely need to add a travis_wait somewhere.

I think some of the customizations used here are no longer needed. For example, one can specify that a xenial image be used for testing, see https://github.com/matthew-brett/multibuild. There may also be a manylinux2014 image available which has a newer gcc.

Understanding the inner workings of multibuild is hard enough. Adding bespoke customizations makes things even harder to understand.

The BUILD_COMMIT variable is not being set, see https://github.com/stan-dev/httpstan-wheels/runs/1560819086?check_suite_focus=true.

httpstan 4.2 was tagged 6 days ago. There was a successful run of the scheduled task 3 days ago. The 4.2 wheel was not uploaded.

Tests pass on the main repository. They fail here.

Main repository (locally built wheel):

• ubuntu bionic
• Python 3.7.6, pytest-5.4.3, py-1.8.1, pluggy-0.13.1
• pytest plugins: asyncio-0.10.0, cov-2.9.0

This repository (manylinux wheel):

• ubuntu xenial
• Python 3.7.7, pytest-5.4.3, py-1.8.1, pluggy-0.13.1
• plugins: asyncio-0.12.0, cov-2.9.0

I believe this is the source of the problem:

PYTHON_CFLAGS ?= $(shell python3 -c 'import sysconfig;print(" ".join(sysconfig.get_config_vars("CFLAGS")))')

gives this on GitHub Actions

-Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch arm64 -arch x86_64 -g

I think -arch arm64 is causing the problems. Not sure why this is being set by default.