Move code from pillow-wheels

[radarhere]

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

• I re-enabled branches and pull requests at https://app.travis-ci.com/github/python-pillow/pillow/settings.
• While I've added a commit to only run it on tags, it does not seem possible to filter TravisCI builds based on file changes. There is no mention of this at https://docs.travis-ci.com/user/conditions-v1, and https://travis-ci.community/t/how-to-skip-jobs-based-on-the-files-changed-in-a-subdirectory/2979 said it wasn't possible earlier this year. I think we can work around this by triggering manual builds to test it when it is necessary.
• TravisCI will obviously not upload the wheels as GitHub Actions artifacts. It instead uploads them to GitHub releases. Maybe that's better?

[radarhere]

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

Ok, done.

[aclark4life]

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

[hugovk]

• While I've added a commit to only run it on tags, it does not seem possible to filter TravisCI builds based on file changes. There is no mention of this at docs.travis-ci.com/user/conditions-v1, and travis-ci.community/t/how-to-skip-jobs-based-on-the-files-changed-in-a-subdirectory/2979 said it wasn't possible earlier this year. I think we can work around this by triggering manual builds to test it when it is necessary.

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?

[radarhere]

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

[hugovk]

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]

[radarhere]

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]

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]

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]

Yes, good idea! Thanks!

[radarhere]

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]

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