Trigger builds with custom config from our UI

[lislis]

Folks who took a close look at our docs may have already discovered the Trigger Build API. It has already been present in our previous v2 API and is of course also present in the current v3 API.

Now we have the this functionality also available in our web client. Read our blog post for more information.

If you have any feedback for us please let us know in this ticket!

[matthewd]

Hi! I just tried this out... I clicked More options -> Trigger build, left branch as master, and in custom config I entered:

addons:
  postgresql: "9.4"
dist: precise

But the resulting build didn't seem to do that: https://travis-ci.org/rails/rails/jobs/271323346/config

Did I do something wrong? :confused:

[iriberri]

Hi @matthewd, thanks for bringing this issue to our attention! I could reproduce the behavior you describe in your comment and our team is taking a further look at this. We'll keep you posted as soon as we have more information or the issue is solved.

Thanks for your patience.

[iriberri]

@matthewd the issue has been fixed, thanks again for reporting it. Could you please give this a try and let us know how it goes? Thanks!

[matthewd]

@iriberri 👌🏻 perfect, thank you!

[gdubicki]

When is the branch list in the web ui updated? Because I have pushed a new tag (v0.17.2 in https://github.com/egnyte/gitlabform repo) about 30 minutes ago and I still don't see it there..

[bokobza]

Hi, My list of branches in the triggering build modal only shows 'master' and an old inactive branch. I can't see any of my new branches and I can't delete the old one (it's not even there on GitHub). Is there any way to refresh this list? This is my repo in case it helps: https://github.com/bokobza/StratisBitcoinFullNode Thanks 😄

[backspace]

Hey, sorry for the delay in responding, @gdubicki. If this happens again, could you let us know if refreshing the tab causes the branch to show? It’s my suspicion that that’s not the case, but if it does help, we could trigger a refresh of branches when the dialogue opens.

I think the true problem is that we don’t currently have tracking for new branches that are created on GitHub. If you manually sync from your profile page, the UI will eventually know about the new branch, but I imagine that is a hassle. Can you describe the workflow you’re experiencing this problem with?

@bokobza, our API is returning the deleted branch with a flag indicating that it no longer exists on GitHub; I’ve changed the UI so it no longer shows those branches in the select.

As for the new branches, we’re entirely dependent on GitHub for what branches a repository has, and all I see there is master:

[cotsog]

@stephencornelius suggested as an improvement on this feature that it would be nice to be able to trigger a build on pull requests. :)

[alibitek]

Yes! It would be very nice to be able to start a rebuild on pull request triggered build jobs!

Case in point, build jobs often fail due to errors outside of the changes made in the pull request, e.g. environment setup or travis runner overload or timeouts when pulling dependencies:

• "curl: (7) Failed to connect to dl.google.com port 443: Connection timed out"
• "The job exceeded the maximum time limit for jobs, and has been terminated."
• The command "sudo -E apt-get -yq --no-install-suggests --no-install-recommends --force-yes install libstdc++6 fonts-droid clang-format-5.0" failed and exited with 100 during .

As a pull request submitter you have no control over these issues. If the build fails you have to manually trigger another build by force pushing into the git branch and hope everything goes well this time.

https://blog.travis-ci.com/2017-08-24-trigger-custom-build mentions that you can trigger builds from the web client using the "Trigger build" option. However, as a user with no commit access to the project and while logged in into travis-ci.org, I cannot see "Trigger build" menu option in the "More options" menu. Example failed job: https://travis-ci.org/flutter/plugins/jobs/323672495

How can I trigger a rebuild from the web UI without doing a manual trigger again and without closing and reopening the pull request? As mentioned in https://stackoverflow.com/questions/17606874/trigger-a-travis-ci-rebuild-without-pushing-a-commit

Tried the Travis CLI client and it doens't allow to restart build jobs outside your own fork. When I try to run travis restart 1283 it says build 1283 has been restarted but if you go and look in the web ui, there is no rebuild going on.

I think a web option should be available, where people who submit pull requests can rerun failed build jobs for their own PRs even when they do not have write/collaborator access to the project.

[allejo]

So when commits are pushed in bulk, only the latest commit will be tested in travis. It would be nice if you could trigger a build for a specific commit hash if you'd like to test one of those untested commits to see where something broke.

[fabiocarvalho777]

Hello. Could someone help me to understand why this customer build of mine failed? There are no error messages whatsoever in the console, or anywhere. By the way, it looks like the console messages just truncate, or stop, abruptly.

[iriberri]

Hi @fabiocarvalho777 - I've been taking a look at the build you shared with us and I think the problem there is unrelated to the topic we're covering in this GitHub issue. Could you please drop us an email to support@travis-ci.com? We'd be glad to take a further look!

Thank you.

[fabiocarvalho777]

@iriberri ok, I will send an email. Thanks Carla.

[drd]

One bit of UX feedback: I tried to copy and paste some values while out and about from my iPhone, but I was unable to get a proper text insertion cursor in the textarea (presumably due to modal dialog re-centering js?) ... I would tap in the field, hold to get a cursor, and then things would jump around when the keyboard popped up, and the field would blur. Otherwise, excited to use this! (Though I still haven't quite figured out if I specify the merge mode here or in my .travis.yml? — would be helpful to clarify this!)

[nakulkorde]

Is there an update on this? I have the same issue. I pushed a new branch on github but I am unable to see that in the drop down for trigger custom build.

[brandondrew]

Thank you for adding this—it is a very valuable features. However, this is not listing all of the branches in my project. What determines what shows up in the list of branches?

It appears at first glance that you have a bug which prevents branches with a / in the name from appearing in the list. Since it is standard in many projects to have a / in virtually all names except "master", this would be a problem.

[acnagy]

Hullo errybody! Just to let you know, I'm eying shipping this (widely-used) beta to GM like very soon, so any last bugs you find are super helpful. That said, to answer the last few questions "recently":

@drd @nakulkorde - ah, good to know re:missing dropdown and/or misplaced cursors. I'll see if I can replicate it on mobile. There's an interesting question though about triggering builds from mobile - if it's got a solid use case? sounds like it's something you do regularly? As to the merge_mode stuff - whatever you put in the config box will be used for the .travis.yml - so you should set merge_mode there if you want to use it on a UI/API triggered build

@brandondrew interesting... if that's a bug (sounds like it might be?), I'm wondering if you run into it on all the dropdowns and places specifying branches e.g. the Settings --> Crons page or the Branches page. Do you see the same missing branches there?

[henrygab]

Bug Title:

UI does not show branches that have no changes since initial config

Steps to Repro:

1. Setup GitHub account with various depots, each with 2+ branches. a. https://github.com/henrygab/zora-sharp with branches master and gh-pages b. https://github.com/henrygab/rust-fatfs with branches master and more_fixes
2. Signup to TravisCI for first time, using GitHub integration, etc.
3. Verify both depots can successfully build master branch using triggered build feature
4. Attempt to build any branch other than master from those GitHub depots using triggered build feature
5. Go to travis-ci.com home page for the profile, and manually 'Sync' with GitHub
6. Attempt to build any branch other than master from those GitHub depots using triggered build feature
7. Push a new branch to one of the depots e.g., https://github.com/henrygab/zora-sharp/tree/CodeStyle
8. Attempt to build gh-pages branch in zora-sharp depot using triggered build feature
9. Attempt to build CodeStyle branch in zora-sharp depot using triggered build feature

Expected results:

At each attempt to use the triggered build feature, branches other than master are available via the drop-down list.

Actual results:

At steps 4 and 5, the UI will only show the branch "master". At steps 8 and 9, the UI still does not show the branch gh-pages, but does show the branch CodeStyle.

Strawman Thoughts:

Based on the above, it appears that there is a bug in the initial configuration. Specifically, web-UI triggered builds appear to not be able to build branches (other than master), if those branches already existed when initially setting up travis-ci.

Open Questions:

• Will any commit to a branch cause the branch to appear?
• Will adding or removing a tag cause the branch to appear?

Any ideas? This is a fresh setup... no legacy anything.

[nmoinvaz]

It appears that it is not possible to trigger a custom build on a tag. The tag does show in the list of branches, but Travis doesn't treat it as a tag and doesn't deploy when on.tags = true in the travis.yaml. The only way to trigger a build on a tag appears to be that I have to delete the remote tag and then repush it.

[dagguh]

So when commits are pushed in bulk, only the latest commit will be tested in travis. It would be nice if you could trigger a build for a specific commit hash if you'd like to test one of those untested commits to see where something broke.

This is critical for TDD. If you follow red-green-refactor workflow, you want to show that the test is red first. This requires triggering old commits within a branch/PR.

[backspace]

Sadly, no one will see posts to this thread or repository, so I don’t recommend putting energy into writing things up here.

[AbhinavArora95]

A hack that worked for me (I have builds on Pull Requests enabled). If a branch B is missing in the trigger build UI, just make a pull request with base as Branch B. After that it should be visible in the trigger build UI.

[MariadeAnton]

We've updated the branches selector so that any branches available on GitHub are also available in the trigger build UI by searching for them. Could you confirm it works for you all? Thank you!

[bdon-hash]

I want to add an additional environment variable for a custom build trigger, but it overwrites all of the environment variables I have in .travis.yml.

[jas88]

As to the merge_mode stuff - whatever you put in the config box will be used for the .travis.yml - so you should set merge_mode there if you want to use it on a UI/API triggered build

Unfortunately not - at least in the current implementation (and documentation as per https://github.com/travis-ci/docs-travis-ci-com/pull/2812/files ), the merge_mode setting has to be passed to the API separately from the YAML - meaning it can't be set through the web UI, forcing the (IMO completely useless!) "merge" mode rather than the obvious "replace".

For the time being I seem to have managed to trigger a replace mode build by triggering a build in the wrong mode, using Chrome dev-tools to copy the HTTPS request as a CURL script then editing it to put merge_mode in the right place. Adding a UI element to select merge_mode directly would be very welcome please!

[padamstx]

The ability to set one or more environment variables while triggering the custom build would be very useful. Currently, if I enter something like env: VAR1=VALUE1 in the "custom config" entry field of the "Trigger Build" dialog, it completely replaces the "env" section of my .travis.yml file, when I really just wanted to add an additional env var.

[aaratn]

Passing below configuration as per this blog post

env:
  - FOO=BAR
  - BAR=FOO

Triggers two jobs

It also overrides the default build configuration like language and other things defined in .travis.yml

Passing below configuration as per the documentation triggers single build but still overwrites configuration

env:
  - FOO=BAR BAR=FOO

[Doogiemuc]

Kudos to the Travis team. And thank you so much for providing your service to the open source community.

But may I politely point you to something from another point of view: "Travis, the most famous continuus integration tool publishes an awesome new feature: Now you can even trigger a build!"

Plesae don't get me wrong. Of course I (and most probably everyone here) knows, that builds are automatically triggered, when an author pushes a new (tagged) commit to his git repo. But what I wanna say: Most beginners most probably don't know this. And this fact is also not easy to find in the travis documentation.

So I suggest you describe this in more detail somewhere at the top of the "Hello World Getting Started guide".

[dharikhan]

Hi Team, i am facing issue while creating build i am getting rejecting and select language as python but it is taking by default as ruby why.

can you please help some one here---> https://travis-ci.com/github/dharikhan/reciepe-app-api

[rlalik]

I have problem with custom build. The config I am putting into the form apparently is concatenated to the config from .travis.yml, and this is not what I expect. The custom build should completely overwrite the one provided by the repo.

Problem described already here: https://travis-ci.community/t/trigger-build-mess-up-config/10955/5

..:: EDIT

I fixed it by using API. But I would still suggest that web form should work in the replace mode, not merge. It seems more natural.

[eyalroz]

I'm also having trouble with the custom build - the .travis.yml I type in is not exactly / not at all what gets used. Example

[eyalroz]

Also, it would be nice if the Trigger Build dialog cached branch names after looking them up, rather than looking them up again and again. Even a client-side cache would be fine.

[Mikhus]

I definitely have a problem triggering build on specific tags, them are simply not listed and I have no ability to specify it manually in this case... Is it possible to resolve somehow this problem, because time-to-time for some reason Travis just missing start a build on a specific tag and I need to re-tag once more, to get build done in a proper manner due to our build process logic...