On Thu, Aug 8, 2019 at 4:24 PM Antoine Pitrou <anto...@python.org> wrote:

>
> Le 08/08/2019 à 16:12, Krisztián Szűcs a écrit :
> > Hi All!
> >
> > Ursabot now supports debugging failed builds with attach attaching
> > shells to the still builds right after a failing build step:
> >
> > $ ursabot project build --attach-on-failure `AMD64 Conda C++`
> >
> > And local source/git directories can also be mounted to the builder
> > instead of cloning arrow, this makes the debugging a lot easier:
> >
> > $ ursabot project build -s ~/Workspace/arrow:. 'AMD64 Conda C++'
> >
> > Mount destination `.` is relative to the build directory on the workers.
> >
> > The CI configuration for arrow is available here:
> > https://github.com/ursa-labs/ursabot/tree/master/projects/arrow
>
> As I've already said: most build configuration should *not* be in the
> buildmaster configuration.  Otherwise this forces a unique build
> configuration (for all branches, for all PRs) and this also forces to
> restart the buildmaster when changing the build configuration (which is
> not a good idea).
>
> Compare with Travis-CI or other services:
> - the CI configuration and scripts are local to the Arrow repository
>
This is the plan, to move the arrow configuration into the arrow repository
to be governed by the arrow community.

> - each PR or branch can change the CI configuration without impacting
> other builds
>
We can introduce an automatism for that, but it has security concerns.
Worst case scenario we can run the ursabot builders on any public CI
services, like we actually run the arrow builders on the ursabot repository:
https://travis-ci.org/ursa-labs/ursabot/builds/569364742

> - one can change the CI configuration without having to restart a global
> daemon or service
>
With a self-hosted infrastructure it is not that easy, at least involves
security
concerns. But we can still develop it, if it is a desired feature.

>
> Regards
>
> Antoine.
>

Reply via email to