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)