Skip to content
This repository has been archived by the owner on Jun 9, 2021. It is now read-only.

Make it possible to know that this is a nightly build from the Travis script #12

Open
ldionne opened this issue Mar 23, 2016 · 11 comments

Comments

@ldionne
Copy link

ldionne commented Mar 23, 2016

Right now, IIUC, there's no way for the Travis script to know that the current job was launched by Nightli.es. It would be very useful to be able to know this, since we could perform custom tasks in the nightly build. Our use case is automatically updating a benchmark suite every night; we don't want to run the suite on each push to master, but only when the build is triggered by Nightli.es.

@brunocodutra
Copy link

+1

@thoralf-gutierrez
Copy link

+1

My use case is to run unit tests only on regular builds that are triggered with each PR and also run longer full integration tests on builds that are triggered by nightlies.

Looks like the Travis API to trigger builds allows to override some of the configuration in the travis.yml, so this should be theoretically possible. I don't have time to come up with a PR though :-/

@thoralf-gutierrez
Copy link

I've just investigated how we could implement this, and I don't see a nice way to do it with the current state of the Travis API.

I wanted to automatically set a NIGHTLIES environment variable when a build has been triggered by nightlies, similar to the TRAVIS environment variable that Travis automatically set for its builds.

The Travis API allows you to overwrite the environment variables that you set in your .travis.yml, but unfortunately it only allows to completely overwrite them, you can't just add one. So if we want to add the NIGHTLIES env variable, we need to know all of the original env variables that are set in the .travis.yml. I haven't found a nice way to retrieve them, so the only option I see would be to re-enter all those variables in the nightlies UI ...

Exploring the Travis documentation though, I've found out that they do set a TRAVIS_PULL_REQUEST whenever the build comes from a PR. I'll probably just use that for now, to trigger longer integration tests only when something gets merged to master.

@coderanger
Copy link
Owner

Hmm, one option would be to have your build script poke the Travis API (the build ID should be available in an env var I think) and check the build type or message. I'll leave this open because that's a weird and annoying fix but I think that's the best approach for now.

@akutz
Copy link

akutz commented Apr 28, 2016

Hi @thoralf-gutierrez,

Actually you can add an environment variable according to the docs I reviewed just now.

image

So knowing this, would it be difficult to add an environmental variable called "NIGHTLIES"?

Or better yet, give us a way via the Nightl.ies app to specify .travis.yml snippets to add as part of our config? I'd love to make my nightly build use the Trusty beta instead of a containerized build so I can do extended testing with things not possible as part of a container build agent.

@thoralf-gutierrez
Copy link

Hi @akutz. Yeap, you can add config keys, but you won't be able to add environment variables to the env key. The env key will be overwritten, as explained in their next paragraph ("Keys in the request's config override any keys existing in the travis.yml"). I tested it on my local setup and that's indeed what happened.

@akutz
Copy link

akutz commented Apr 28, 2016

Hi @thoralf-gutierrez,

You know, I still think that's okay if you give us the option to include a snippet because I for one could just edit my script command to use make to point to a specific target. Or if you could just touch a file on the system so we could detect it, it would serve the same purpose as an env var?

@akutz
Copy link

akutz commented Apr 28, 2016

Hi @thoralf-gutierrez,

Also, thank you for responding so quickly and politely even after I asked a dumb question to which you were already familiar with the answer. I guess I missed the original bits :)

@akutz
Copy link

akutz commented Apr 28, 2016

Hi @thoralf-gutierrez,

So I just triggered this build with the following snippet:

#!/bin/sh

body='{
    "request": {
        "branch": "master",
        "message": "nightly build via awesome-o",
        "config": {
            "script": "make info"
        }
    }
}'

curl -s -X POST \
    -H "Content-Type: application/json" \
    -H "Accept: application/json" \
    -H "Travis-API-Version: 3" \
    -H "Authorization: token $TRAVIS_TOKEN" \
    -d "$body" \
    https://api.travis-ci.org/repo/akutz%2Flibstorage/requests

Damn you for being correct on the replacement! :) How useless is that then? "Merge" is far from accurate as far as I'm concerned as it only merges top-level keys. Come on Travis! Deep merge needed!

@coderanger
Copy link
Owner

We could possibly grab the configured env vars from the last build and implement the merge locally but down this path likely lies madness.

@thachhoang
Copy link

As of May 2016, Travis now supports cron jobs: travis-ci/travis-ci#582. If triggered by cron, a build will have the environment variable TRAVIS_EVENT_TYPE set to cron. You have to email Travis support to get the feature though.

If you'd rather stick with Nightli.es, and nothing else is using the Travis API to launch your builds, you could check if TRAVIS_EVENT_TYPE is api.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants