• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

Qiskit / qiskit-sqd / 38992528199
91%

Build:
DEFAULT BRANCH: main
Ran 17 Oct 2026 01:51AM UTC
Jobs 1
Files 7
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

17 Oct 2026 01:50AM UTC coverage: 82.878%. Remained the same
38992528199

push

github

web-flow
Test against qiskit pre-release wheels from PyPI (#401)

* Test against qiskit pre-release wheels from PyPI

The qiskit 2.6.0 release broke this repository's notebook tests on Linux, and
nothing in CI saw it coming even though 2.6.0rc1 had been on PyPI for two
weeks. `Development version tests` builds qiskit from a git checkout with
`python -m build`, which does not enable the mimalloc feature the release
pipeline does. mimalloc's C component is compiled -ftls-model=initial-exec,
which sets DF_STATIC_TLS on the whole _accelerate.abi3.so and forces every
thread-local in it -- including the one that grew -- into the small pool glibc
keeps for libraries dlopen'ed after startup. Built without mimalloc that
thread-local is ordinary general-dynamic TLS and never touches the pool, so
the source build cannot exhibit the failure however often it runs. See
Qiskit/qiskit#17213.

So add a workflow that installs the published pre-release wheel instead of
building one. An exact `==` pin naming a pre-release opts in just that
package, leaving every other dependency on a final release; `--pre` would
admit pre-releases of everything.

It runs only while a pre-release is the newest qiskit on PyPI. Once the final
release lands, `Latest version tests` resolves the same wheel and this would
be redundant, so the first job checks and the test job is skipped. The check
reads PyPI rather than the GitHub releases API: PyPI only lists a version once
its wheels are uploaded, which is the artifact under test, whereas a tag shows
up roughly an hour earlier and would start runs with nothing to install.
Ordering is PEP 440 via packaging, not `sort -V`, which ranks 2.6.0rc1 above
2.6.0 and would leave a stale pre-release winning forever.

Replaying the check against the index as it stood on 2026-10-10 selects
2.6.0rc1, so this would have run during the rc window.

Assisted-by: Claude Opus 5

* Remove extraneous comments

668 of 806 relevant lines covered (82.88%)

0.83 hits per line

Jobs
ID Job ID Ran Files Coverage
1 38992528199.1 17 Oct 2026 01:51AM UTC 7
82.88
GitHub Action Run
Source Files on build 38992528199
  • Tree
  • List 7
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line
  • Back to Repo
  • Github Actions Build #38992528199
  • 6201dc4a on github
  • Prev Build on main (#38982247662)
  • Next Build on main (#38992796950)
  • Delete
STATUS · Troubleshooting · Open an Issue · Sales · Support · CAREERS · ENTERPRISE · START FREE TRIAL · SCHEDULE DEMO
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2026 Coveralls, Inc