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 <bgerstle(a)wikimedia.org>
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 <cananian(a)wikimedia.org>
wrote:
On Fri, Oct 2, 2015 at 11:50 AM, Brian Gerstle
<bgerstle(a)wikimedia.org>
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
Wikitech-l(a)lists.wikimedia.org
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
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l