Info?

[jakirkham]

This seems interesting. What is the plan here?

[PeterDSteinberg]

With merge of PR #12 we have the ability to submit builds to win-64, linux-64, osx-64 for any of conda-recipes packages.

Outstanding items are related to the operation of the build workers:

• Do we leave them running and listening for jobs?
• Do we start up build workers on demand (easy for linux at this point with anaconda-cluster plugin)
• Do we have git commit webhooks that trigger builds on commit, and if so, to which branches and to what depth to build the dependencies, or
• Do we just use this submit helper to submit packages

[msarahan]

I think more generally, the idea is to better support CI of recipe-repositories. We would like to improve the quality of the conda-recipes repository without the requirement of creating any additional work, as conda-forge requires. It would also be great to create a CI system that bridges all platforms. This project is also a dog-fooding opportunity for us in using the Anaconda build system.

This project itself will likely not be used, but will likely become a set of tools that can be placed into another package tree, to build out that package tree using the Anaconda build system..

[jankatins]

I currently run such a conda-recipes repository, using the conda smithy infrastructure: https://github.com/JanSchulz/package-builder/

After the setup, it's currently a "add a commit for a new version of a package" workload.

The nicest thing was, that I was able to add automatic pypi uploads in a conda recipe: https://github.com/JanSchulz/package-builder/tree/master/recipes/pypandoc :-)

[groutr]

Automatic PyPI uploads are nice indeed. I think this project is developing a workflow that is slightly more advanced than conda smithy by being able to build packages beyond/outside a PR if they have a dependency relation with the packages affected by the PR. Example: If numpy is updated, automatically rebuild numpy + all other packages that depend on numpy.