community
community copied to clipboard
dask
Set up CI builds on azure pipelines
I'm volunteering to help set up CI builds for dask on azure pipelines. This should allow us to have more build capacity
@TomAugspurger can you add my user to the dask-dev azure pipelines project you have created?
Sure. Can you send me your username on azure-pipelines?
On Tue, Aug 6, 2019 at 10:47 AM Marius van Niekerk [email protected] wrote:
I'm volunteering to help set up CI builds for dask on azure pipelines. This should allow us to have more build capacity
@TomAugspurger https://github.com/TomAugspurger can you add my user to the dask-dev azure pipelines project you have created?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dask/community/issues/1?email_source=notifications&email_token=AAKAOIXLIWVWVWIJAUQL6OTQDGMJRA5CNFSM4IJXY6H2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HDVOGYQ, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKAOIRAPSPRETMX2RLJPBLQDGMJRANCNFSM4IJXY6HQ .
@dask/dask-dev send me an email with your Microsoft account username / email if you'd like permission on https://dev.azure.com/dask-dev
I did this for xarray a month or two ago. There's probably something useful you can borrow from our configuration, and if you implement any new tricks, let me know!
So since the dask org is biggish -- I think its probably a good idea to create a dask-bot user on github that has some degree of access to the org so that we can scope the permissions it has more cleanly.
Right now if we bind auth to any particular user it brings in all of their personal stuff as well, which is undesirable.
I love the idea of using a bot. I would be happy to look into this at some point.
I maintain opsdroid in my spare time and would advocate for using that.
Why would we want to use a bot over the standard azure-pipelines setup? A bot becomes more code we have to maintain, and hosting we potentially have to pay for. What benefits does a bot bring? With travis/appveyor we've been fine with using the standard setup so far, I'd think it would be the same with azure pipelines.
One use case is actions that are not triggered by builds of the current project. For example raising a PR against one project as a result of a release of another project.
I agree with your view that CI/CD should be primary.