Travis is not integrated with gitlab, so it's not really relevant here. *If* travis adds gitlab integration *and* we switch our current github mirror to gitlab *then* it could be something to look at. Neither of those preconditions are currently met.
We're not using any "new" github features, just the standard github mirror that gerrit already maintains (and presumably any future change review system would as well). --scott On Fri, Oct 2, 2015 at 7:00 PM, Brian Gerstle <[email protected]> wrote: > Ah of course, my misunderstanding. (I even mentioned pushing to git in my > last email). > > > > If we wanted to keep build > > artifacts around "forever", we could easily do so; > > > How would you get artifacts of a build done inside a Travis VM? > > In any case, this still involves going through GitHub. Is anyone > evaluating GitLab-CI <https://about.gitlab.com/gitlab-ci/>? Apparently > their "runner" service can run on OSX (and Windows & Linux). > > On Fri, Oct 2, 2015 at 1:20 PM, C. Scott Ananian <[email protected]> > wrote: > > > On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle <[email protected]> > > wrote: > > > > > Lastly, it appears that Travis's build-triggering API is still in beta > > > > > <http://docs.travis-ci.com/user/triggering-builds/>, and there's no > > mention > > > of polling builds in this way. > > > > > > I don't use this API, and it's not really suitable in any case. I just > use > > the standard stable API for watching builds on a branch. Trigger is > > automatic with the push, which is a boring old git push, via the git CLI. > > > > If someone were to try using this with one > > > or more projects (e.g. Android) and decide to move forward, would we > > reach > > > out to Travis to ask when the current API will be marked as stable or > if > > > they would be willing to work with us to develop an API more suited to > > our > > > needs? > > > > > > Not sure exactly what that would be. The only oddity in the current > setup > > is that I clean up the branch right after the build is complete -- but > > that's not an inherent property of the process. If we wanted to keep > build > > artifacts around "forever", we could easily do so; I just wanted to > ensure > > things were uncluttered in the github "branches" pulldown. > > > > I'm all about doing what it takes to get the job done*, but just > > > wanted to be sure that were aware that this might not be the most > stable > > > way to use Travis. > > > > > > There's nothing unusual about triggering travis builds by pushing to a > > branch. > > > > The only thing that's interesting at all is that our branch names have > > slashes in them, and that issue was resolved a year ago: > > https://github.com/travis-ci/travis-api/pull/146 > > > > That property of our branch names was also optional; we used dashes > instead > > of slashes as a workaround. But it does let us integrate better with > gerrit > > access control mechanisms, which are built around slash-delimited branch > > names. > > --scott > > > > -- > > (http://cscott.net) > > _______________________________________________ > > Wikitech-l mailing list > > [email protected] > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > > > > > -- > EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle > IRC: bgerstle > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- (http://cscott.net) _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
