Conditional build without triggering TravisCI VMs

Travis CI Discussions & Feedback
, , ,
1

I have been looking at the docs and also trying out various experimental changes with the .travis.yml file in order to toggle my builds based on if there have been code-related changes in a project or it’s just documentation related changes.

So far the issue isn’t as urgent as it might get in time when more developers push and create PRs, all those users who haven’t made changes have to unfairly wait for previous builds to finish especially if those previous builds are triggered by non-code related changes.

We have put up a solution to check for this in the before_install directive and it then skips the build with the help of an exit 0.

But it still takes 30-40 seconds before the PR is released from build. Subsequent commits and PRs are waiting in the queue. We think this can be improved further if we didn’t trigger the TravisCI VM’s, and were able to do the same checks at the github hook level. We want to optimise it further than in a few seconds we can see if our PR needs a CI/CD build or not.

Any thoughts or ideas about this? Has someone solved this already - sounds like a common issue others might have as well.

2

What have you tried?

https://docs.travis-ci.com/user/conditional-builds-stages-jobs/ might give you an idea.

3

Thanks for the feedback, I have already looked into it and found I can’t express my complex conditions with the language it provides.

Maybe I haven’t seen deeper docs or examples of what I’m looking for:

  • basically git knows what files one has changed in a commit or branch (which is a commit as well). If this information is available in TravisCI env variable that’s one piece of info
  • In my case I’m looking for file extensions, so similarly the same info can be made available in an environment variable or a directive, whichever works
  • the expressions language should allow expressing things like:
    ${TRAVISCI_COMMIT_FILE_EXTENSIONS} contain any of (xx xxx x xyz)

or

    ${TRAVISCI_COMMIT_FILE_EXTENSIONS} does not contain any of (xx xxx x xyz)

And if the above return true of false we can then add that condition to an environment variable or directly call it via the if directive:

if: <condition>

or

if: <do not run build if no code changes have been made directive>

or

if: <run build only if code changes have been made directive>

Thats my basic understanding atm, of course its not precise what I described above but then looking at the docs and functionality available we can bridge the gap.

This functionality on its own, if TravisCI can provide via a single directive can save everyone a lot of build time and waiting for the build to start because the build is stuck in the queue occupied by other builds that are executing commits or branch triggers of non-code related changes.

I hope this is clearer than before.

4

git knows what files one has changed

@neomatrix369 cloning the git repository happens on the VM, after the build has started. so preventing this wait time based on the git repository won’t work.

we could, in theory, inspect the payload that GitHub sends to us, which may contain the same information, when we accept the build request. i am not sure how reliable that then would be though. sometimes push events coming in from GitHub are huge.