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
