Add CI about pyinstaller-hooks-contrib

[htgoebel]

Scheduled monthly build and release for the hooks is what we are aiming for, aren't we? So this is perfectly fine.

But: Why not run these schedule from the PyInstaller team? So all builds will seen under travis-ci.org/pyinstaller.

Regarding credentials: Using your personal ones is okay for me. But maybe you do not want to put your personal credentials into the CD settings?! PyPI seems to not have "api-keys". So maybe we'd better create a "pyinstaller" account? WDYT?

Tanks for you PyPi account name, I added you as an owner.

[htgoebel]

@Legorooj Go ahead.

[htgoebel]

All of the pipelines run the tests on python 3.5, 3.6, 3.7, once for pyinstaller development version and once for the stable release

Cool! Many thanks!

[bjones1]

What CI systems are provided by Github actions? Looking at https://github.com/marketplace?type=actions, I don't see Travis or Appveyor support. This means developing CI from scratch on a new platform, correct?

[htgoebel]

This is curious: We use both travis and appveyoralready for PyInstaller core.

[Legorooj]

@bjones1 (@htgoebel) GitHub actions is CI. They provide - with unlimited minutes for public repos - Linux, macOS, and Windows testing.

The actions in that link are tools to help your CI as such; pypa have one called publish-pakage or something, which does all of the twine stuff for you, with tokens you provide. Other actions are use-python-3.7 etc.

See https://help.github.com/en/actions/getting-started-with-github-actions/about-github-actions for info.

[bjones1]

It's a fair-sized project to get a new CI system running from scratch -- making sure the correct compilers are installed and in the path, X windows screen emulation, correct libraries for each OS, etc. So, it's not simply a matter of running a few pip installs then testing. I'd suggest staying with the current CI system, and making this a separate issue/project.

[Legorooj]

@bjones1 compilers/path/tools aren't a problem; everything we could possibly want is available, installed and ready. Screen emulation as well.

Stages are available, so one for each OS. Each stage will have a job for each python version we want to test - though matrix style testing might be easier. I'll have a play around on another repo, and see if it all works fine.

Anyway, if we use other providers, this issue still addresses them: it's just add CI.

[htgoebel]

I'd prefer to not use github actions for CD/CI, as this is binding us to github even more - and I want to avoid vendor lock-in. Test-setup for travis already exists at https://github.com/pyinstaller/hooksample, resp. bjones' fork
I just actiated CI at https://travis-ci.org/github/pyinstaller/pyinstaller-hooks-contrib/ and https://ci.appveyor.com/project/PyInstaller/pyinstaller-hooks-contrib

For Appveyor I added the respective roles and permission For Travis I did not find any permission settings -( Please let me know if something is missing

[Legorooj]

@htgoebel I use GitHub auth with Travis and AppVeyor, which means they see I'm in the PyInstaller org and give me restart/cancel access. That should be enough.

I'd like to do a CD pipeline (with Azure Pipelines; with GitHub actions I can't automate it) - scheduled monthly build - that builds an sdist, wheel, uploads them to PyPI, and makes a release on GitHub. All would be done under my private account, and with my private GitHub creds, so as far as anyone could see, I might as well have done it myself (the release/tag/upload etc) Would that be alright? (Of course the project would be one with public visibility, and the yaml would be kept in this repo, so anyone could tweak it.)

Also, can I have access to the PyPI package? I need that anyway, whether its a manual or automated release. PyPI usename is Legorooj (https://pypi.org/user/Legorooj/)

[Legorooj]

What I mean for personal credentials is the automated release would bump the version in the package and push back into the repo. Travis can't do that easily; Azure Pipelines can.

PyPI has and would use tokens, yes - if you'd like an example of an automated release I have currently, see https://github.com/fluffykoalas/sloth/blob/dev/.azure-pipelines/release-generator-and-uploader.yml. It's not scheduled and doesn't bump the version, but otherwise is similar to what I'd do for this. Azure Pipelines - because Microsoft runs GitHub to an extent, has an API that uses the GitHub social auth for pushing back into the repo, meaning "I" would be bumping the version.

I've got a private repo with an example - scheduled/automated - that I'll invite you to.

[Legorooj]

@htgoebel quick request: Can we put Linux CI on Travis, Windows on AppVeyor, and macOS on GitHub actions? Actions is easier to configure.

Also, we should consider shelling out the lint checks to Actions in the PyInstaller main repo. I'm always annoyed that lint is the last thing checked, and this way we'd get the results faster.

[htgoebel]

@Legorooj This is fine for me.

Rational: Basically I do not care about which CI we are using, But: We should avoid vendor lock-in as far as possible. And we should avoid promoting commercial or proprietary services - even if they are "free". I'm aware of we are failing on both of this currently. Anyway I would prefer to no adding yet another service (azure), as this locks us in even more.

[Legorooj]

@htgoebel I understand your reasons. Also, I'll only be using Azure for release because it allows me to automate it - with manual triggers or scheduling - and docutils has a bug in it which means you can't render RST READMEs on Windows propely, so you need Linux. That means I can't do it locally.

[Legorooj]

Whoo! CI is finally done. I've written virtually identical test pipelines for Linux (Travis), Windows (AppVeyor), and macOS (GitHub actions). All of the pipelines run the tests on python 3.5, 3.6, 3.7, once for pyinstaller development version and once for the stable release. I just need to write the auto-releaser pipeline now...