On Tue, 14 Nov 2017 at 10:57 Lev Lazinskiy <lev@circleci.com> wrote:
Hi team!

I recently submitted a PoC PR to the dev guide repo [1] that shows how this repo could be built on CircleCI.

The immediate problem that I was trying to solve was to get a free and easy way to store the linkchecker results as a build artifact. A couple of things to note about that build:

1. The entire build (including linkcheck) ran in under 1 minute.
2. We are able to store the build output as artifacts.
3. We can also store the HTML of the build as preview to make it easy to see the entire dev guide site in its state for any commit.

Brett commented on the PR and mentioned that there may be a few hurdles in getting the python organization to adopt CircleCI, so I would love to get a conversation going.

One thing that Brett mentioned was that there is a limit to the number of concurrent builds that can run at any given time. By default, for all open source projects CircleCI offers four free containers which means you can run four builds at a time (for any project in a given org).

I spoke to our developer advocate team and we would be happy to provide the python organization with a total of 15 containers at no cost.

OK, so this is where I get confused by the Circle CI pricing docs every time. :) So above you said "four free containers ... for any project in a given org". Does that mean by default it's four builders per repo or per organization on GitHub? My guess is it's the latter since you're offering 15 builders for the Python organization as a whole.

Another question for me is does any of this include macOS builders?

Basically the only real complaints we have received from developers about Travis is performance due to how long it takes to run our builds. This also bleeds into macOS support as we have simply turned it off due to the time it has traditionally taken to get a macOS builder on Travis for open source projects. This has also been an issue at PyCon US during the sprints when python/cryptography managed to suck up all the builders the Python organization shared (we learned afterwards that had we notified Travis ahead of time we could have gotten a builder increase for that week to handle the unusual load).

So for me, I think that if Circle CI can give us:
  1. We can move our .travis.yml over without losing functionality
  2. Faster builds than Travis
  3. macOS builds which are reliably scheduled
  4. Can give us temporary increases during PyCon US if we share builders across the organization

then I think this may be worth discussing.

-Brett


 

Thank you for your time and I am looking forward to hearing from you soon!

[1] https://github.com/python/devguide/pull/294


--
Best,
Lev Lazinskiy
Operator Experience Team Lead | CircleCI
_______________________________________________
core-workflow mailing list
core-workflow@python.org
https://mail.python.org/mailman/listinfo/core-workflow
This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct