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. > > > > > > > > > > >
