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

Move code from pillow-wheels #7418

Merged
merged 1,004 commits into from
Oct 2, 2023
Merged

Move code from pillow-wheels #7418

merged 1,004 commits into from
Oct 2, 2023

Conversation

radarhere
Copy link
Member

@radarhere radarhere commented Sep 23, 2023

Helps #7390

As suggested in that issue, moves the https://github.com/python-pillow/pillow-wheels code into this main repository, in order to simplify the release process.

I have setup the new "Wheels" job to be triggered on

  • manual builds
  • changes to the workflow file or the wheels directory
  • tags.

Regarding TravisCI

radarhere and others added 30 commits May 14, 2022 10:08
Updated openjpeg to 2.5.0, except on macOS x86_64
Updated openjpeg to 2.5.0 on macOS x86_64
Deploy to GitHub Releases when a tag is set
Updated auditwheel to include auditwheel#376
Removed symlink as Pillow now checks /usr/local/lib/libfribidi.dylib
updates:
- [github.com/pre-commit/pre-commit-hooks: 8fe62d14e0b4d7d845a7022c5c2c3ae41bdd3f26 → 3298ddab3c13dd77d6ce1fc0baf97691430d84b0](pre-commit/pre-commit-hooks@8fe62d1...3298dda)
@radarhere
Copy link
Member Author

Would it be possible to add the new files, preserving Git history from the old repo where possible?

Ok, done.

@aclark4life
Copy link
Member

Not entirely sure why, but I'm excited about the pillow-wheels code moving here (rollin' rollin' rollin') thanks @radarhere @hugovk

wheels/README.md Outdated Show resolved Hide resolved
@hugovk
Copy link
Member

hugovk commented Sep 27, 2023

Hmm, that's unfortunate, it's been requested since at least 2016, and I think only admins of this repo/org can trigger manual builds now?

There's a couple of workarounds at travis-ci/travis-ci#6301 (comment) and travis-ci.community/t/how-to-skip-jobs-based-on-the-files-changed-in-a-subdirectory/2979/12?u=hugovk

But probably worth splitting out from this PR to make things easier to test/review.

I'm currently most concerned about not being able to run Travis CI except during releases. I don't want us to find out on release day something has broken.

Can we try these workarounds and/or split Travis CI into its own PR?

Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
@radarhere
Copy link
Member Author

Ok, I've pushed a commit. TravisCI will run every time, but will exit early if the conditions are not met.

@hugovk
Copy link
Member

hugovk commented Sep 28, 2023

Thanks!

Hmm, now I'm wondering if (lots of builds) x (exiting early) will nevertheless eat up our credits...

However, it looks like non-admins like us can restart builds and jobs (e.g. at https://app.travis-ci.com/github/python-pillow/Pillow/builds/266245399), and also trigger new builds, which is good.

@aclark4life The credits page that is only visible by admins. Please can you paste some screenshots of the current credits usage?

https://app.travis-ci.com/organizations/python-pillow/plan

@aclark4life
Copy link
Member

Screenshot 2023-09-28 at 7 18 02 AM

@radarhere
Copy link
Member Author

radarhere commented Sep 28, 2023

If tags and manual builds are too infrequent,
and early exiting all of the time (and continuing when relevant) is too frequent,
is tags, manual builds and a cron the middle path?

Or we could restrict Travis to tags and manual builds, and use python-pillow/pillow-wheels#367 for a cron?

@hugovk hugovk mentioned this pull request Sep 29, 2023
5 tasks
@hugovk
Copy link
Member

hugovk commented Sep 29, 2023

At first I thought only admins could do manual builds, and thought that we'd only get builds for tags during release, which would be too infrequent. But happily I was wrong about that.

What we need is to build from tags for releases. That's fine.

Plus to be able to do some builds in between releases to prevent surprises. Manual builds is okay for that.

Plus, what I think is missing is to be able to see the results of PR changing the Travis related files. I guess we'll just have to hope for the best, merge, then do a manual build and iterate as needed?

@radarhere
Copy link
Member Author

Ok, I've removed the commit to run Travis every time.

Plus, what I think is missing is to be able to see the results of PR changing the Travis related files.

If there was concern, which I expect there isn't most of the time, we could push the PR as a branch to Pillow, and then trigger a Travis build of that Pillow branch.

@hugovk
Copy link
Member

hugovk commented Oct 2, 2023

Yes, good idea! Thanks!

@hugovk hugovk merged commit b7010a9 into python-pillow:main Oct 2, 2023
85 checks passed
@radarhere radarhere deleted the pillow-wheels branch October 2, 2023 20:43
DavidKorczynski pushed a commit to google/oss-fuzz that referenced this pull request Oct 27, 2023
Two changes for the pillow project.

1. Pillow previously had a separate repository for wheel building
scripts - https://github.com/python-pillow/pillow-wheels

However, that has been incorporated into the main repository for
simplicity - python-pillow/Pillow#7418

So this PR updates the project here to use the new location.

2. Pillow's oss-fuzz CI job is [currently failing because pip is too
old](https://github.com/python-pillow/Pillow/actions/runs/6666944851/job/18119459590#step:4:9947).
So this PR updates it.

cc @hugovk

---------

Co-authored-by: Andrew Murray <radarhere@users.noreply.github.com>
@radarhere
Copy link
Member Author

radarhere commented Oct 29, 2023

Previously, when we've done point releases, dependency updates merged into pillow-wheels were automatically incorporated into the newly released wheels.

With this change though, that will no longer be the case, so we may want to take a moment when creating point releases to consider whether any dependency updates are important and should be cherry-picked in.

@hugovk
Copy link
Member

hugovk commented Oct 29, 2023

Yes, good idea, let's keep it in mind when planning point releases.

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.

4 participants