Skip to content

test: run unit tests for each built wheel - #1432

Merged
jdavid merged 3 commits into
libgit2:masterfrom
2bndy5:wheels-test-with-cibuildwheel
Oct 13, 2025
Merged

test: run unit tests for each built wheel#1432
jdavid merged 3 commits into
libgit2:masterfrom
2bndy5:wheels-test-with-cibuildwheel

Conversation

@2bndy5

@2bndy5 2bndy5 commented Oct 13, 2025

Copy link
Copy Markdown
Contributor

Uses cibuildwheel to run unit tests on each binary wheel built (natively, without qemu).

This could replace the current tests.yml workflow as it more accurately represents user experience during tests.

If removing test.yml in favor of this patch, then I would also adjust the CI triggers for wheels.yml (to run in PR sync events). See also #1366 for additional proposal.

@2bndy5
2bndy5 marked this pull request as draft October 13, 2025 09:53
@2bndy5

This comment was marked as resolved.

@2bndy5
2bndy5 marked this pull request as ready for review October 13, 2025 11:29
@2bndy5

2bndy5 commented Oct 13, 2025

Copy link
Copy Markdown
Contributor Author

I had to fix an assertion that was too broad for the test requirements. I also have to skip testing wheels built when qemu is involved (ppc64le).

Otherwise, the tests are running fine on native built wheels (x86, x64, arm). 🎉

@jdavid
jdavid merged commit d16e2f3 into libgit2:master Oct 13, 2025
8 checks passed
@2bndy5
2bndy5 deleted the wheels-test-with-cibuildwheel branch October 13, 2025 18:35
@jdavid

jdavid commented Oct 14, 2025

Copy link
Copy Markdown
Member

This is cool. Now as you said we could replace the tests workflow, and run this instead.
To do this I think we need two changes:

  • Most of the time is spent in the ppc build, this should only run in the master branch.
  • The tests workflow runs for the s390x platform too, but they fail. I think we should keep the tests workflow but run it only in the s390x platform, and only in master. If in the future the tests are fixed for this platform, then move it to the wheels. I would keep the workflow tests.yml so it does not add a new entry, and just change the name to "Tests (s390x)".

What do you think? Will you make a new PR?

@2bndy5

2bndy5 commented Oct 14, 2025

Copy link
Copy Markdown
Contributor Author

What do you think? Will you make a new PR?

Sure. That sounds rather easy enough.


BTW, What's the procedure for updating the CHANGELOG? Is that dependent on maintainers? Is there interest in auto-creating a GitHub release (when a tag is pushed) with auto-generated notes?

@jdavid

jdavid commented Oct 14, 2025

Copy link
Copy Markdown
Member

I maintain the changelog, so far it's not much of a burden, so I didn't bother with automating it.

@2bndy5

2bndy5 commented Oct 14, 2025

Copy link
Copy Markdown
Contributor Author

Yeah, automating the changelog is best done with conventional-commit messages (the format I've been using for all my PR titles).

It would be easy to add a step to wheels.yml pypi job:

    - name: Create GitHub Release
      env:
        GITHUB_TOKEN: ${{ github.token }}
        TAG: ${{ github.ref_name }}
        REPO: ${{ github.repository }}
      # https://cli.github.com/manual/gh_release_create
      run: >-
        gh release create ${TAG} 
        --verify-tag
        --repo ${REPO}
        --title ${TAG}
        --generate-notes

That way, people watching this repo will be notified when you push a new tag.

@2bndy5 2bndy5 mentioned this pull request Oct 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants