Is it possible to test CUDA under a Docker container?

I feel like I'm the only person who routinely tests CUDA on my home
machine :-) And of course I only do that on Linux...

Regards

Antoine.


On Fri, 21 Jun 2019 12:23:10 -0500
Wes McKinney <wesmck...@gmail.com> wrote:
> hi folks,
> 
> I would suggest the following development approach to help with
> increasing our CI capacity:
> 
> 1. For all Linux builds, refactor Travis CI jobs to be Docker-based
> and not depend on Travis-CI-specific state or environment variables
> 2. Add such jobs to Ursabot. If there is satisfaction with the service
> provided by these builds, then the Travis CI entry can be toggled off,
> but we should preserve the Travis CI configuration so they can be
> turned back on
> 
> I'm not sure what to do about Windows and macOS jobs.
> 
> Obvious initial candidate for this process is the lint job, to give
> faster linter failures on PRs which currently can take a while
> 
> Thoughts?
> 
> - Wes
> 
> On Mon, Jun 17, 2019 at 3:48 PM Krisztián Szűcs
> <szucs.kriszt...@gmail.com> wrote:
> >
> > That's right, OWNER, MEMBER and CONTRIBUTOR roles are allowed:
> > CONTRIBUTOR
> >
> > Author has previously committed to the repository.
> > MEMBER
> >
> > Author is a member of the organization that owns the repository.
> > OWNER
> >
> > Author is the owner of the repository.
> > See https://developer.github.com/v4/enum/commentauthorassociation/
> >
> > On Mon, Jun 17, 2019 at 3:16 PM Wes McKinney <wesmck...@gmail.com> wrote:
> >  
> > > On Mon, Jun 17, 2019 at 7:25 AM Krisztián Szűcs
> > > <szucs.kriszt...@gmail.com> wrote:  
> > > >
> > > > On Sun, Jun 16, 2019 at 6:17 AM Micah Kornfield <emkornfi...@gmail.com>
> > > > wrote:
> > > >  
> > > > > Hi Krisztian,
> > > > > This is really cool, thank you for doing this.   Two questions:
> > > > > 1.  How reliable is the build setup? Is it reliable enough at this  
> > > point to  
> > > > > be considered a merge blocker if a build fails?
> > > > >  
> > > >  IMO yes.
> > > >  
> > > > > 2.  What is the permission model for triggering runs?  Is it open to
> > > > > anybody on github?  Only Ursalab members?  Committers?
> > > > >  
> > > > Most of the builders are automatically triggered on each commits.
> > > > Specific control buttons are available for ursalabs member at the 
> > > > moment,
> > > > but I can grant access to other organizations (e.g. apache) and  
> > > individual  
> > > > members.
> > > >  
> > >
> > > You're talking about the Buildbot UI here? Suffice to say if any CI
> > > system is going to be depended on for decision-making, then any
> > > _contributor_ needs to be able to trigger runs. It seems that
> > > presently any contributor can trigger builds from GitHub comments, is
> > > that right?
> > >  
> > > > >
> > > > > Thanks,
> > > > > Micah
> > > > >
> > > > > On Fri, Jun 14, 2019 at 2:30 PM Antoine Pitrou <anto...@python.org>  
> > > wrote:  
> > > > >  
> > > > > >
> > > > > > Le 14/06/2019 à 23:22, Krisztián Szűcs a écrit :  
> > > > > > >>
> > > > > > >> * Do machines have to be co-located on the same physical network 
> > > > > > >>  
> > > as  
> > > > > > >> the master, or can they reside in other locations?
> > > > > > >>  
> > > > > > > It is preferable to have a master in the same network where the  
> > > workers  
> > > > > > are,  
> > > > > > > because the build steps are rpc calls made by the master.  
> > > > > >
> > > > > > I'm unaware that this is a problem.
> > > > > > CPython has build workers all over the world (contributed by  
> > > volunteers)  
> > > > > > connected to a single build master.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Antoine.
> > > > > >  
> > > > >  
> > >  
> 



Reply via email to