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

Travis pricing change, limited build minutes, adjustments needed, github actions? (2300) #1176

Closed
5 tasks
GalacticEmperor1 opened this issue Feb 12, 2023 · 0 comments

Comments

@GalacticEmperor1
Copy link
Collaborator

Issue №2300 opened by illume at 2020-11-05 09:13:22

https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing

TLDR;

  • time limit added to builds (1000 minutes)
  • mac builds will be very limited
  • unsure when the new plan starts for the pygame organization. They say they are introducing it incrementally.
  • unsure where to see used minutes in the travis ci interface.

Actions to consider:

  • move mac builds to github actions.
  • move manylinux builds to github actions.
  • move sdist build?
  • pypi uploads working (could be on appveyor or github)
  • github uploads working (could be on appveyor or github)

Comments

# # ankith26 commented at 2020-11-05 09:29:06

Well, thats bad news. Ok, I will start using [skip ci] from now

For a heavy CI user like me ;) who commits every little change made, we have to move to github actions quickly :)


# # illume commented at 2020-11-05 14:50:04

Committing every change is fine, maybe just consider pushing it only when you're at the end of coding a session (or even in some days after).


# # ankith26 commented at 2020-11-05 15:52:24

Well, now that I’m using git, things will be better, I used to use the github web interface, so even to like change something in another file, I would have to do a separate commit


# # zoldalma999 commented at 2020-11-07 17:11:12

I dont know how many people read it but i think we should add a note in Hacking to use [skip ci] if they are just changing the documentation or do it on their own fork if possible (and possibly redirect to a link which explains how to do that).


# # ankith26 commented at 2020-11-09 03:32:35

Just noticed (in my latest commit), travis has stopped running (even though I forgot to use [skip ci] )


# # MyreMylar commented at 2020-11-13 19:46:22

Hmm, read through their blog and it does sound bad for pretty much all big open source projects using Travis CI.

Big shove to move all their free users over to Github Actions I suppose? I'll have a poke around the other similar projects to pygame and see if they are moving off Travis already (if they were on it)


# # MyreMylar commented at 2020-11-13 19:59:00

Looks like numpy recently made the jump to github actions. See this PR:

numpy/numpy#17738

As did Pillow in this issue and the linked PRs:

python-pillow/Pillow#5028

Looks like a fairly wide consensus to ditch Travis from those projects that were using it.


# # ankith26 commented at 2020-11-18 10:27:07

What’s the current situation with this issue, should we still be doing [skip ci] on our commits??


# # illume commented at 2020-11-20 09:34:47

Seems like they are shutting things down on December 31st now, and it appears there's still no reporting of used minutes. So I guess we are maybe ok until then (it's still unclear though).

ps. There was the gh zero day revealed at the start of the month... and they've been deprecating pretty much everything since... so I guess gh actions will be ever more different as the months go on. Ultimately the only proper fix is for them to redo things in an entirely different way.

Project Zero researcher Felix Wilhelm noted: "The way workflow commands are implemented is fundamentally insecure."

I still want to do a 2.0.1.dev2 release out with Travis, and then do a 2.0.1 release before starting to move things over.


# # hugovk commented at 2020-11-20 09:56:46

travis-ci.org is shutting down by the end of the year, you'll need to migrate to travis-ci.com, which is nominally still "free" for open source, but they give trial credits to begin with and then you need to either pay for a plan or contact support to request free minutes, if the project meets their requirements.

https://docs.travis-ci.com/user/migrate/open-source-repository-migration

My credits ran out after two weeks and so far I've had no success in getting any OSS credits and can now no longer test my own projects or other projects on Travis CI.

You can see how many minutes pygame used for the last month here, 12,607 minutes:

image

https://travis-ci.org/github/pygame?tab=insights


# # illume commented at 2020-11-21 16:38:32

Thanks for the info @hugovk


# # MyreMylar commented at 2020-11-21 17:16:47

Well if Travis don't count pillow as a valid open source project I doubt they'll count pygame either.

These appear to be the deprecated commands with the main security vulnerability in github actions:

https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/

Seems to mostly affect workflow actions which run on issues (which anyone can create) so probably won't cause too much bother if we steer away from those two commands and use it for CI.


# # hugovk commented at 2020-11-21 17:41:11

Well if Travis don't count pillow as a valid open source project I doubt they'll count pygame either.

We haven't actually asked for credits at Pillow yet, but have moved as much as we can to GHA mainly due to the uncertainty (also get more parallel builds at GHA).

We still have some stuff on Travis which can't be migrated to GHA (like unique CPU architectures), so we'll probably have to request soon, and hopefully the project will meet the criteria, unless Tidelift is a problem.

Here's the mail Travis sent me when I requested for some of my own projects. Not had any granted yet.

Hello there,

Thanks for contacting Travis-CI Support! I'd love to help!

We offer an Open Source Subscription for free to all non-commercial open-source projects. To qualify for an Open Source subscription, the project must meet the following requirements:

  • You are a project lead or regular committer (latest commit in the last month)
  • Project must be at least 3 months old and is in active development (with regular commits and activity)
  • Project meets the OSD specification
  • Project must not be sponsored by a commercial company or organization (monetary or with employees paid to work on the project)
  • Project can not provide commercial services or distribute paid versions of the software
    Sounds like you and your project? We'd be very happy to support you. If your project does not match these requirements or you have questions, feel free to ask!

Looking forward to your response if you meet these requirements to proceed with the next steps.


# # illume commented at 2020-12-21 18:20:42

I forgot to post this link here: https://blog.travis-ci.com/oss-announcement The TLDR; is they managed to stop the groups using lots of resources on bitcoin mining and such. There's also now a notice about closing down the .org travis "in several weeks". So the situation is a bit different than it was initially.

Anyway, I started a local branch refactoring the CI code so it can run where ever in preparation.

With gihub actions, we get 3000 free minutes. With Mac minutes being special - and costing 10 minutes.

If we use 12,607 travis minutes (which are also not CPU minutes, but wall clock minutes) then github actions by itself are not enough. That could cost $100-$1000/month on github actions.

Since github actions are free for public repos... we don't need to reduce our used minutes for that reason.

Here's a few ideas of the top of my head to reduce minutes:

  • improve speed of jobs (like the mac job takes a long time installing dependencies still).
  • Try and suggest people use tox testing/some sort of pre-commit "make check" type thing first. So less typos are pushed.
  • better structuring of jobs, so a pre-flight job can do lint and run the tests before running other platforms.
  • I just manually run mac jobs locally for every PR. (doesn't really scale when I'm away, and isn't instant feedback)
  • hook up our own mac/linux/other build machine(s).
  • pay for another concurrent job on appveyor at $25/month for foss projects (it does mac/linux now too).
  • only have minimal running on PRs, and more jobs only on request.
  • smarter merge jobs (why run the jobs again on the same tree after merge?)
  • skipping CI on docs/ changes automatically
  • try to get less people contributing ;)

[Edit: github actions are free for public repos, thanks @hugovk]


# # hugovk commented at 2020-12-21 18:32:53

If we use 12,607 travis minutes (which are also not CPU minutes, but wall clock minutes) then github actions by itself are not enough. That could cost $100-$1000/month on github actions.

GitHub Actions is free for public repos.


# # ankith26 commented at 2021-05-24 03:16:54

Now that github actions PR is merged in, the only tasks left should be managing releases from github actions


# # illume commented at 2021-08-15 11:29:03

So... there's a new note from Travis about how if you use ARM or PPC they offer the service again.
https://blog.travis-ci.com/2021-06-16-ibm-aws

Building on ARM would be useful for at least the manylinux builds and also to try to keep our PPC builds working. Using qemu is 5x slower to build ARM images. PPC builds are useful to keep things working for Debian, but also for catching bugs on all platforms.

Let's see if it actually does work though...


# # illume commented at 2021-08-15 12:01:49

After a bit of clicking and fussing, it seems to work. Well, I don't see any 'free oss credits', but they give 10,000 free minutes. So we'll see how that goes. Only the arm64 build is on there.

I guess this issue can be closed. We mostly migrated to github actions and appveyor.

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

No branches or pull requests

1 participant