New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crons : Simple scheduled builds for your repositories #1

Closed
joshk opened this Issue Dec 4, 2016 · 146 comments

Comments

Projects
None yet
@joshk
Member

joshk commented Dec 4, 2016

Earlier this year we dark shipped a new feature for running scheduled builds for repositories, which we called Crons.

This feature was developed with the help from some amazing students at HPI University in Potsdam, Germany.

You can find current, and up to date docs for Crons here: https://docs.travis-ci.com/user/cron-jobs/

This feature is going into General Availability on the 6th of December.

Please leave all feedback related to this feature here as comments.

UPDATE: 2017-01-20

I wanted to give a quick update that I'll being going through all the feedback shortly and provide some information on when this will come out of Beta and what improvements we have lined up.

Thank you everyone for your feedback!

UPDATE: 2017-02-02

Thanks a lot for your feedback everyone!

I am adding each of the suggested changes below for votes.

Once we have gathered votes over a few weeks, we will decide which of these can be implemented earliest to be able to get Crons out of Beta.

UPDATE: 2017-03-02
We have started working on fixing and improving some things to move Crons out of Beta, details here.

@alvy54

This comment has been minimized.

Show comment
Hide comment
@alvy54

alvy54 Dec 5, 2016

I've been using it for a few months now to schedule tests. I wish I could update the time that the job runs.

alvy54 commented Dec 5, 2016

I've been using it for a few months now to schedule tests. I wish I could update the time that the job runs.

@bsideup

This comment has been minimized.

Show comment
Hide comment
@bsideup

bsideup Dec 6, 2016

I re-generate the metadata with Travis by triggering it from AWS Lambda. Was really excited to switch to Travis' native cron, but "daily" is way too rarely.

Any chance to get "every 5 minutes"?

bsideup commented Dec 6, 2016

I re-generate the metadata with Travis by triggering it from AWS Lambda. Was really excited to switch to Travis' native cron, but "daily" is way too rarely.

Any chance to get "every 5 minutes"?

@bmcfee

This comment has been minimized.

Show comment
Hide comment
@bmcfee

bmcfee Dec 6, 2016

Great feature!

I just tried this on a couple of my repositories, and it fails to add with the following errors on the js console:

raven.js:1062 GET https://api.travis-ci.org/v3/repo/3969047/crons 403 (Forbidden)

bmcfee commented Dec 6, 2016

Great feature!

I just tried this on a couple of my repositories, and it fails to add with the following errors on the js console:

raven.js:1062 GET https://api.travis-ci.org/v3/repo/3969047/crons 403 (Forbidden)
@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Dec 6, 2016

Member

Hi @bmcfee, thanks for the error report, could you try doing a reload/refresh of the page and see if that helps. If it doesn't, could you please email support@travis-ci.com and we can look into this.

Member

joshk commented Dec 6, 2016

Hi @bmcfee, thanks for the error report, could you try doing a reload/refresh of the page and see if that helps. If it doesn't, could you please email support@travis-ci.com and we can look into this.

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Dec 6, 2016

Member

@alvy54 Thanks for the feedback. We are looking at making this information editable in a future release, possibly in Q1 or Q2 in 2017.

Member

joshk commented Dec 6, 2016

@alvy54 Thanks for the feedback. We are looking at making this information editable in a future release, possibly in Q1 or Q2 in 2017.

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Dec 6, 2016

Member

@bsideup Thanks for the feedback. We are considering other interval choices, but it is unlikely we will add 'every 5 mins' for the time being. I will provide more context around this in Q1 once we do some further planning around the next iteration of Crons.

Member

joshk commented Dec 6, 2016

@bsideup Thanks for the feedback. We are considering other interval choices, but it is unlikely we will add 'every 5 mins' for the time being. I will provide more context around this in Q1 once we do some further planning around the next iteration of Crons.

@zmwangx

This comment has been minimized.

Show comment
Hide comment
@zmwangx

zmwangx Dec 6, 2016

For the record, I'm having the same problem as bmcfee, and I've sent an email to support@travis-ci.com with details. Please don't hesitate to ask if you need additional info, thanks.

zmwangx commented Dec 6, 2016

For the record, I'm having the same problem as bmcfee, and I've sent an email to support@travis-ci.com with details. Please don't hesitate to ask if you need additional info, thanks.

@bsipocz

This comment has been minimized.

Show comment
Hide comment
@bsipocz

bsipocz Dec 6, 2016

This looks like a great feature, thanks. Just another +1 to the request to have other interval option, a week is too often, a month is too rare.
Also would be great to have more option (that scale with the interval) for skipping, e.g. running fortnightly only when there was no build in the last week?

bsipocz commented Dec 6, 2016

This looks like a great feature, thanks. Just another +1 to the request to have other interval option, a week is too often, a month is too rare.
Also would be great to have more option (that scale with the interval) for skipping, e.g. running fortnightly only when there was no build in the last week?

@bsipocz

This comment has been minimized.

Show comment
Hide comment
@bsipocz

bsipocz Dec 6, 2016

It looks like that I'm not able to add the cron job to a project I maintain (astropy/astroquery), I suppose the jobs should be listed as in the blogpost's screenshot?

Edit: looking at the console, this seems to be the same problem reported above.

bsipocz commented Dec 6, 2016

It looks like that I'm not able to add the cron job to a project I maintain (astropy/astroquery), I suppose the jobs should be listed as in the blogpost's screenshot?

Edit: looking at the console, this seems to be the same problem reported above.

@nden

This comment has been minimized.

Show comment
Hide comment
@nden

nden Dec 6, 2016

👍 to this feature. I am also having trouble adding a cron job to public repos with a similar error as reported by @bmcfee

nden commented Dec 6, 2016

👍 to this feature. I am also having trouble adding a cron job to public repos with a similar error as reported by @bmcfee

@joshk

This comment has been minimized.

Show comment
Hide comment
@joshk

joshk Dec 6, 2016

Member

Thank you for the comments and feedback about the issues you are experiencing in setting up your first Cron schedule.

We are looking into the issue now and will provide an update shortly.

For the time being, please add an emoji reaction of 😕 to this comment if you are experiencing issues adding a Cron schedule to a repository.

Member

joshk commented Dec 6, 2016

Thank you for the comments and feedback about the issues you are experiencing in setting up your first Cron schedule.

We are looking into the issue now and will provide an update shortly.

For the time being, please add an emoji reaction of 😕 to this comment if you are experiencing issues adding a Cron schedule to a repository.

@backspace

This comment has been minimized.

Show comment
Hide comment
@backspace

backspace Dec 6, 2016

Member

We have deployed API changes that should properly enable crons for all. Can anyone who was having a problem before try it again and let us know if it doesn’t work?

Member

backspace commented Dec 6, 2016

We have deployed API changes that should properly enable crons for all. Can anyone who was having a problem before try it again and let us know if it doesn’t work?

@zmwangx

This comment has been minimized.

Show comment
Hide comment
@zmwangx

zmwangx Dec 6, 2016

It works now, thanks.

zmwangx commented Dec 6, 2016

It works now, thanks.

@bsipocz

This comment has been minimized.

Show comment
Hide comment
@bsipocz

bsipocz Dec 6, 2016

@backspace - Adding the job works for me, and it also started the build. Thanks.

bsipocz commented Dec 6, 2016

@backspace - Adding the job works for me, and it also started the build. Thanks.

@backspace

This comment has been minimized.

Show comment
Hide comment
@backspace

backspace Dec 6, 2016

Member

Excellent, thank you. We expect it should work for everyone now. You can leave a 👍 on my post if it’s working for you now when it didn’t before. If it’s still broken, please leave a comment!

Member

backspace commented Dec 6, 2016

Excellent, thank you. We expect it should work for everyone now. You can leave a 👍 on my post if it’s working for you now when it didn’t before. If it’s still broken, please leave a comment!

@bsipocz

This comment has been minimized.

Show comment
Hide comment
@bsipocz

bsipocz Dec 6, 2016

As a feature request, I wonder whether you consider to add an option to have a separate config file for the cron jobs, or to be able to add extra builds to the matrix that would only run when the build is started from a cron job? It would be a nice workaround to travis-ci/travis-ci#6774 where I seek a way to have builds that only run on master, but not on PRs.

EDIT: anyone using conda environments for their setup may be interested in https://github.com/astropy/ci-helpers. I've added the EVENT_TYPE env variable to control whether to run a build for the given event or not (events are the same as for TRAVIS_EVENT_TYPE: cron, pull_request, push or api)

bsipocz commented Dec 6, 2016

As a feature request, I wonder whether you consider to add an option to have a separate config file for the cron jobs, or to be able to add extra builds to the matrix that would only run when the build is started from a cron job? It would be a nice workaround to travis-ci/travis-ci#6774 where I seek a way to have builds that only run on master, but not on PRs.

EDIT: anyone using conda environments for their setup may be interested in https://github.com/astropy/ci-helpers. I've added the EVENT_TYPE env variable to control whether to run a build for the given event or not (events are the same as for TRAVIS_EVENT_TYPE: cron, pull_request, push or api)

@joshk joshk self-assigned this Dec 6, 2016

@ntwb

This comment has been minimized.

Show comment
Hide comment
@ntwb

ntwb Dec 7, 2016

As a feature request, I wonder whether you consider to add an option to have a separate config file for the cron jobs, or to be able to add extra builds to the matrix that would only run when the build is started from a cron job?

To offer up an alternative use case for this functionality WordPress has just added an official GitHub mirror this morning https://github.com/WordPress/wordpress-develop, I'd like to add a daily cron job that tests the codebase against all the major releases of MySQL and MariadDB. There is no need to test against all these databases for every commit so a daily cron job is ideal.

ntwb commented Dec 7, 2016

As a feature request, I wonder whether you consider to add an option to have a separate config file for the cron jobs, or to be able to add extra builds to the matrix that would only run when the build is started from a cron job?

To offer up an alternative use case for this functionality WordPress has just added an official GitHub mirror this morning https://github.com/WordPress/wordpress-develop, I'd like to add a daily cron job that tests the codebase against all the major releases of MySQL and MariadDB. There is no need to test against all these databases for every commit so a daily cron job is ideal.

@colszowka

This comment has been minimized.

Show comment
Hide comment
@colszowka

colszowka Dec 7, 2016

Great to have this feature! I would really appreciate if the starting time could be configurable - usually I'd prefer to have the automated builds happen at night when nobody's working on the code. A simple dropdown for picking the base hour for all cron jobs (instead of using whatever time it was at initial setup time) would alreay do the trick.

Regarding the request by @bsipocz I can imagine much of this could be solved by simply adding a special env variable that flags automated builds, something along the lines of TRAVIS_CRON_SCHEDULED=yip

Great to have this feature! I would really appreciate if the starting time could be configurable - usually I'd prefer to have the automated builds happen at night when nobody's working on the code. A simple dropdown for picking the base hour for all cron jobs (instead of using whatever time it was at initial setup time) would alreay do the trick.

Regarding the request by @bsipocz I can imagine much of this could be solved by simply adding a special env variable that flags automated builds, something along the lines of TRAVIS_CRON_SCHEDULED=yip

@backspace

This comment has been minimized.

Show comment
Hide comment
@backspace

backspace Dec 7, 2016

Member

I’ll leave the other feedback for Josh to respond to, but regarding the environment variable idea, @colszowka, there already is one! You can check TRAVIS_EVENT_TYPE for the value cron to know a job was triggered this way. 🎉

Member

backspace commented Dec 7, 2016

I’ll leave the other feedback for Josh to respond to, but regarding the environment variable idea, @colszowka, there already is one! You can check TRAVIS_EVENT_TYPE for the value cron to know a job was triggered this way. 🎉

@bsipocz

This comment has been minimized.

Show comment
Hide comment
@bsipocz

bsipocz Dec 7, 2016

@backspace - Thanks, this is very useful to know, I think this case I can easily have a workaround script by using this or the other newly recognized variable TRAVIS_PULL_REQUEST from here https://docs.travis-ci.com/user/customizing-the-build#Implementing-Complex-Build-Steps.

bsipocz commented Dec 7, 2016

@backspace - Thanks, this is very useful to know, I think this case I can easily have a workaround script by using this or the other newly recognized variable TRAVIS_PULL_REQUEST from here https://docs.travis-ci.com/user/customizing-the-build#Implementing-Complex-Build-Steps.

@hawkrives

This comment has been minimized.

Show comment
Hide comment
@hawkrives

hawkrives Dec 7, 2016

I've got a use-case for having a separate config for Cron jobs, I think — I don't want to queue up OS X builds for every PR; I'd much rather do one per day. However, if I list the OS X build in my env matrix, it gets queued up no matter what — I can do an early exit from it, but it's got to start first.

I could use either a separate config or some sort of matrix-job flag for "not on cron-triggered builds", I guess.

(My env matrix has a trusty container, a precise sudo-enabled machine, and an OS X machine, which run JS builds, Android builds, and iOS builds respectively, but I only want the trusty container to run on pushes and PRs. Ideally, I would only trigger the other two from cron.)

I've got a use-case for having a separate config for Cron jobs, I think — I don't want to queue up OS X builds for every PR; I'd much rather do one per day. However, if I list the OS X build in my env matrix, it gets queued up no matter what — I can do an early exit from it, but it's got to start first.

I could use either a separate config or some sort of matrix-job flag for "not on cron-triggered builds", I guess.

(My env matrix has a trusty container, a precise sudo-enabled machine, and an OS X machine, which run JS builds, Android builds, and iOS builds respectively, but I only want the trusty container to run on pushes and PRs. Ideally, I would only trigger the other two from cron.)

@BtbN

This comment has been minimized.

Show comment
Hide comment
@BtbN

BtbN Dec 7, 2016

We are using Crons for our Coverity builds for FFmpeg.
So far everything runs great, with Cron set to trigger daily.

Coverity only allows us 4 builds per week, so right now we have some code that checks the day-of-week and exits out from the build early.
Some way to control the triggers more fine grained than just Daily/Weekly/Monthly would be nice.
Maybe even full crontab style, but limited to one build per day?

We could potentially workaround this by adding 4 weekly triggers, but that would mean someone would have to set up the 4 trigger exactly at the day and time we want them to run.
So some option to set the exact trigger time would help here.

BtbN commented Dec 7, 2016

We are using Crons for our Coverity builds for FFmpeg.
So far everything runs great, with Cron set to trigger daily.

Coverity only allows us 4 builds per week, so right now we have some code that checks the day-of-week and exits out from the build early.
Some way to control the triggers more fine grained than just Daily/Weekly/Monthly would be nice.
Maybe even full crontab style, but limited to one build per day?

We could potentially workaround this by adding 4 weekly triggers, but that would mean someone would have to set up the 4 trigger exactly at the day and time we want them to run.
So some option to set the exact trigger time would help here.

@ellson

This comment has been minimized.

Show comment
Hide comment
@ellson

ellson Dec 7, 2016

Would definitely like to be able to control the hour that it runs (want late night east-coast US time, after most developers have reached a stable state for the day.

Would like to be able to build conditionally on there having been changes since the last build.

Would be satisfied with just nightly builds, and not after every change (many documentation changes don't need an immediate build).

ellson commented Dec 7, 2016

Would definitely like to be able to control the hour that it runs (want late night east-coast US time, after most developers have reached a stable state for the day.

Would like to be able to build conditionally on there having been changes since the last build.

Would be satisfied with just nightly builds, and not after every change (many documentation changes don't need an immediate build).

@sivakumar-kailasam

This comment has been minimized.

Show comment
Hide comment
@sivakumar-kailasam

sivakumar-kailasam Dec 9, 2016

Apart from the predefined hourly/daily/weekly options, would be good to have a custom option where we can enter a custom cron expression

Apart from the predefined hourly/daily/weekly options, would be good to have a custom option where we can enter a custom cron expression

@bgruening

This comment has been minimized.

Show comment
Hide comment
@bgruening

bgruening Dec 11, 2016

Love this feature, works great for month!

Love this feature, works great for month!

@mseminatore

This comment has been minimized.

Show comment
Hide comment
@mseminatore

mseminatore Dec 13, 2016

Just started using it to ensure I am testing daily builds, so far its been great!

Just started using it to ensure I am testing daily builds, so far its been great!

@nigelhorne

This comment has been minimized.

Show comment
Hide comment
@nigelhorne

nigelhorne Dec 13, 2016

Great idea, thanks!

Great idea, thanks!

@drdanz

This comment has been minimized.

Show comment
Hide comment
@drdanz

drdanz Dec 14, 2016

Great feature, it would be even more useful if you could set the time when the build is executed and if these builds could take precedence over all the others. This would allow proper "nightly" builds starting at the chosen hour, even if there is a long queue of other builds.

Also it would be useful to have separated tabs for builds triggered by commits and builds triggered by cron jobs.

By the way, I noticed something weird, I added the build for 2 different branches, and they took the same build number, see this and this. Is this expected?

drdanz commented Dec 14, 2016

Great feature, it would be even more useful if you could set the time when the build is executed and if these builds could take precedence over all the others. This would allow proper "nightly" builds starting at the chosen hour, even if there is a long queue of other builds.

Also it would be useful to have separated tabs for builds triggered by commits and builds triggered by cron jobs.

By the way, I noticed something weird, I added the build for 2 different branches, and they took the same build number, see this and this. Is this expected?

@vmrob

This comment has been minimized.

Show comment
Hide comment
@vmrob

vmrob Dec 14, 2016

My team is using cron jobs to schedule nightly clean builds (no caching dependencies, etc.) and we expect them to take much longer than our standard builds. The ability to decide when jobs run–even if it's a wide range–would be greatly appreciated.

vmrob commented Dec 14, 2016

My team is using cron jobs to schedule nightly clean builds (no caching dependencies, etc.) and we expect them to take much longer than our standard builds. The ability to decide when jobs run–even if it's a wide range–would be greatly appreciated.

@jsmaniac

This comment has been minimized.

Show comment
Hide comment
@jsmaniac

jsmaniac Dec 14, 2016

A lot of people want to specify a precise build time. I'd also like the opposite: check a box saying that I'm flexible concerning the build time.

I'm running weekly or monthly builds to check that updates to third-party dependencies did not break anything in my code. I don't care at what time the build runs — for monthly builds I don't even care about the day, it could be ± 3 days.

I would therefore be happy if I could tell travis-ci.org to run my weekly or monthly builds when the traffic is the lowest (around 4 AM CET), or when the machines are the cheapest (if you're using one of these flexible plans).

A lot of people want to specify a precise build time. I'd also like the opposite: check a box saying that I'm flexible concerning the build time.

I'm running weekly or monthly builds to check that updates to third-party dependencies did not break anything in my code. I don't care at what time the build runs — for monthly builds I don't even care about the day, it could be ± 3 days.

I would therefore be happy if I could tell travis-ci.org to run my weekly or monthly builds when the traffic is the lowest (around 4 AM CET), or when the machines are the cheapest (if you're using one of these flexible plans).

@abioteau

This comment has been minimized.

Show comment
Hide comment
@abioteau

abioteau Dec 15, 2016

It works fine but i would be happy to have a more fine grained trigger like "every hours"

It works fine but i would be happy to have a more fine grained trigger like "every hours"

@xrl

This comment has been minimized.

Show comment
Hide comment
@xrl

xrl Dec 15, 2016

@abioteau why is your project worth running an autobuild every hour? Do you expect your dependencies to change very quickly? Please explain why a project would need so much build resources.

xrl commented Dec 15, 2016

@abioteau why is your project worth running an autobuild every hour? Do you expect your dependencies to change very quickly? Please explain why a project would need so much build resources.

@abioteau

This comment has been minimized.

Show comment
Hide comment
@abioteau

abioteau Dec 16, 2016

@riggerthegeek

This comment has been minimized.

Show comment
Hide comment
@riggerthegeek

riggerthegeek Dec 18, 2016

As well as the weekly/monthly/daily, can we put in our own cron strings?

As well as the weekly/monthly/daily, can we put in our own cron strings?

@mseminatore

This comment has been minimized.

Show comment
Hide comment
@mseminatore

mseminatore Dec 19, 2016

I seem to be unable to add a daily build for a branch. A validation error shows saying I need to select a branch but I have done so.

I seem to be unable to add a daily build for a branch. A validation error shows saying I need to select a branch but I have done so.

@backspace

This comment has been minimized.

Show comment
Hide comment
@backspace

backspace Dec 20, 2016

Member

Hey, @mseminatore, can you let us know what repository and branch this is happening for? Is it on travis-ci.org or travis-ci.com? Alternately, can you write in to support so we can have someone look at it?

Member

backspace commented Dec 20, 2016

Hey, @mseminatore, can you let us know what repository and branch this is happening for? Is it on travis-ci.org or travis-ci.com? Alternately, can you write in to support so we can have someone look at it?

@mseminatore

This comment has been minimized.

Show comment
Hide comment
@mseminatore

mseminatore Dec 20, 2016

@mseminatore

This comment has been minimized.

Show comment
Hide comment
@mseminatore

mseminatore Dec 20, 2016

@bfred-it

This comment has been minimized.

Show comment
Hide comment
@bfred-it

bfred-it Mar 9, 2017

I'd like one more option that's useful to deploy nightlies:

  • build daily, only if there are new commits since the last build

Example:

Do not run if there are no changes since the last build

bfred-it commented Mar 9, 2017

I'd like one more option that's useful to deploy nightlies:

  • build daily, only if there are new commits since the last build

Example:

Do not run if there are no changes since the last build

@austinpickett

This comment has been minimized.

Show comment
Hide comment
@austinpickett

austinpickett Mar 10, 2017

This is awesome. 12hr interval and updated Crons would be very useful.

This is awesome. 12hr interval and updated Crons would be very useful.

@matthew-brett

This comment has been minimized.

Show comment
Hide comment
@matthew-brett

matthew-brett Mar 17, 2017

Excellent feature.

I would love the ability to define extra environment variables for the cron jobs in the GUI. For example, I would like to be able to specify the commit or branch to build, without having to edit my .travis.yml file.

Excellent feature.

I would love the ability to define extra environment variables for the cron jobs in the GUI. For example, I would like to be able to specify the commit or branch to build, without having to edit my .travis.yml file.

@j2kun

This comment has been minimized.

Show comment
Hide comment
@j2kun

j2kun Mar 18, 2017

My general feeling (though this might be possible, I haven't figured out how to do it) is to build on every push to master, but otherwise only build on PRs.

j2kun commented Mar 18, 2017

My general feeling (though this might be possible, I haven't figured out how to do it) is to build on every push to master, but otherwise only build on PRs.

@jd-gascuel

This comment has been minimized.

Show comment
Hide comment
@jd-gascuel

jd-gascuel Mar 19, 2017

Sounds great.
But I have a bug: If I try to add a cron on a specific branch, it insists to do it on master instead...

Sounds great.
But I have a bug: If I try to add a cron on a specific branch, it insists to do it on master instead...

@jcoyne

This comment has been minimized.

Show comment
Hide comment
@jcoyne

jcoyne Mar 22, 2017

Every month seems too infrequent, but every week seems too frequent. How about a biweekly frequency?

jcoyne commented Mar 22, 2017

Every month seems too infrequent, but every week seems too frequent. How about a biweekly frequency?

@itafroma

This comment has been minimized.

Show comment
Hide comment
@itafroma

itafroma Mar 24, 2017

Great feature; would it be possible to have an option to run periodic builds on all open PRs (even if it's more restricted, like it will only periodically build if there hasn't been another build in 24 hours)? It'd be useful to ensure PRs are automatically checked for staleness.

Great feature; would it be possible to have an option to run periodic builds on all open PRs (even if it's more restricted, like it will only periodically build if there hasn't been another build in 24 hours)? It'd be useful to ensure PRs are automatically checked for staleness.

@juju4

This comment has been minimized.

Show comment
Hide comment
@juju4

juju4 Apr 2, 2017

Great feature!
Any option to do it globally? of for a repository pattern? (matching "ansible-*" for example)
Also the do not run option with only 24h timing maybe a bit too hard, not even a week-end without coding ;-). adding 72h/1 week would be nice.

juju4 commented Apr 2, 2017

Great feature!
Any option to do it globally? of for a repository pattern? (matching "ansible-*" for example)
Also the do not run option with only 24h timing maybe a bit too hard, not even a week-end without coding ;-). adding 72h/1 week would be nice.

@christophermaier

This comment has been minimized.

Show comment
Hide comment
@christophermaier

christophermaier Apr 6, 2017

Very useful feature; however, I've noticed that repositories that were running cron jobs daily (and set to Always run) have stopped running recently. On the Settings page, the cron widget will say that a job ran, say, 3 hours ago, but no build has really run in several days. Removing and recreating the cron job has no effect. Some of my repositories continue to run cron jobs like normal, though, so I'm not quite clear on what's happening.

Very useful feature; however, I've noticed that repositories that were running cron jobs daily (and set to Always run) have stopped running recently. On the Settings page, the cron widget will say that a job ran, say, 3 hours ago, but no build has really run in several days. Removing and recreating the cron job has no effect. Some of my repositories continue to run cron jobs like normal, though, so I'm not quite clear on what's happening.

@marvinroger

This comment has been minimized.

Show comment
Hide comment
@marvinroger

marvinroger Apr 6, 2017

@christophermaier

This comment has been minimized.

Show comment
Hide comment
@christophermaier

christophermaier Apr 6, 2017

@marvinroger No, they're just "normal" commits. In fact, they're merge commits that previously ran just fine in TravisCI; they just don't seem to run anymore via the cron feature (even though the cron widget on the settings page of the respective repositories says that they are running).

@marvinroger No, they're just "normal" commits. In fact, they're merge commits that previously ran just fine in TravisCI; they just don't seem to run anymore via the cron feature (even though the cron widget on the settings page of the respective repositories says that they are running).

@desrosj

This comment has been minimized.

Show comment
Hide comment
@desrosj

desrosj Apr 6, 2017

I did not see this mentioned above (might have missed it), but it would be great if you could specify a different configuration file that is used when a cron build is running. I use Travis mostly for unit testing WordPress plugins and themes.

Use Case
When my repository code changes, it should be tested against my normal list of PHP and WordPress versions. But when cron build is running, I can safely assume that the tests will pass on released versions of WordPress, as those code bases don't change once released.

Ideally, I would have a separate config that would only test against the nightly version, and maybe the latest version (in case a new version is released and I don't update my configuration file), the only two codebases that are changing.

desrosj commented Apr 6, 2017

I did not see this mentioned above (might have missed it), but it would be great if you could specify a different configuration file that is used when a cron build is running. I use Travis mostly for unit testing WordPress plugins and themes.

Use Case
When my repository code changes, it should be tested against my normal list of PHP and WordPress versions. But when cron build is running, I can safely assume that the tests will pass on released versions of WordPress, as those code bases don't change once released.

Ideally, I would have a separate config that would only test against the nightly version, and maybe the latest version (in case a new version is released and I don't update my configuration file), the only two codebases that are changing.

@reece

This comment has been minimized.

Show comment
Hide comment
@reece

reece Apr 12, 2017

Thanks for this feature!

I've starting using cron runs to trigger an installation/integration test. My preference would be to instead trigger this test based on the execution of another test. As far as I know, there's no way for a travis test to trigger another travis test. I'd like that feature.

Actually, the ideal would be to represent the tree of dependencies for a test, and to traverse that test much like a Makefile would to test each dependency bottom-up.

reece commented Apr 12, 2017

Thanks for this feature!

I've starting using cron runs to trigger an installation/integration test. My preference would be to instead trigger this test based on the execution of another test. As far as I know, there's no way for a travis test to trigger another travis test. I'd like that feature.

Actually, the ideal would be to represent the tree of dependencies for a test, and to traverse that test much like a Makefile would to test each dependency bottom-up.

@paulmelnikow

This comment has been minimized.

Show comment
Hide comment
@paulmelnikow

paulmelnikow Apr 20, 2017

Thanks for your work on Travis and your service for the open source community. And that I love this feature! It provides exactly what I need. I used every bit of the UI that was there, which I found super intuitive. I also use the environment variable, which restricts my slow tests to the nightly build (so they don't run on every commit or push).

These are the two things I would add, if I could:

  • Separate notification channels for the cron build (my slow nightly tests are integration tests, and therefore very noisy)
  • Intervals shorter than a day

Thanks for your work on Travis and your service for the open source community. And that I love this feature! It provides exactly what I need. I used every bit of the UI that was there, which I found super intuitive. I also use the environment variable, which restricts my slow tests to the nightly build (so they don't run on every commit or push).

These are the two things I would add, if I could:

  • Separate notification channels for the cron build (my slow nightly tests are integration tests, and therefore very noisy)
  • Intervals shorter than a day
@vk496

This comment has been minimized.

Show comment
Hide comment
@vk496

vk496 Apr 21, 2017

I appreciate this feature. Is great detect when a cron job is started with the variable TRAVIS_EVENT_TYPE, but would be useful detect the type of cron job (daily, weekly, ...).

Salu2

vk496 commented Apr 21, 2017

I appreciate this feature. Is great detect when a cron job is started with the variable TRAVIS_EVENT_TYPE, but would be useful detect the type of cron job (daily, weekly, ...).

Salu2

@macandcheese

This comment has been minimized.

Show comment
Hide comment
@macandcheese

macandcheese Apr 26, 2017

I understand not wanting to allow unlimited scheduled builds... how about allowing twice daily builds as well as the option to schedule a time or at least a time range for the build to occur. Thank you for this feature

I understand not wanting to allow unlimited scheduled builds... how about allowing twice daily builds as well as the option to schedule a time or at least a time range for the build to occur. Thank you for this feature

@lrascao

This comment has been minimized.

Show comment
Hide comment
@lrascao

lrascao May 15, 2017

Cron jobs are great, thanks!

A nice add to it would be to allow us to define custom environment variables per cron job, this should probably cover some already mentioned requests

lrascao commented May 15, 2017

Cron jobs are great, thanks!

A nice add to it would be to allow us to define custom environment variables per cron job, this should probably cover some already mentioned requests

@phil-davis

This comment has been minimized.

Show comment
Hide comment
@phil-davis

phil-davis May 15, 2017

It is nice being able to check the value of TRAVIS_EVENT_TYPE as each job (matrix combination) starts up, and thus possibly exit early, so as not to bother running some things unless it is in the cron job.
But that means that each job (matrix combination) still runs (even if it decides to do nothing much), and so the build status has a list of green ticks against all of the jobs. That makes it look as if the jobs actually "did something" and succeeded. (but actually the real content of one of those jobs might be broken - and you will find that out when the regular cron job runs, and everything executes)
It would be nice to have some way to control what is included/excluded from the build matrix based on the TRAVIS_EVENT_TYPE before any matrix combinations are started.
But I can't think how to code that based on the available syntax.

It is nice being able to check the value of TRAVIS_EVENT_TYPE as each job (matrix combination) starts up, and thus possibly exit early, so as not to bother running some things unless it is in the cron job.
But that means that each job (matrix combination) still runs (even if it decides to do nothing much), and so the build status has a list of green ticks against all of the jobs. That makes it look as if the jobs actually "did something" and succeeded. (but actually the real content of one of those jobs might be broken - and you will find that out when the regular cron job runs, and everything executes)
It would be nice to have some way to control what is included/excluded from the build matrix based on the TRAVIS_EVENT_TYPE before any matrix combinations are started.
But I can't think how to code that based on the available syntax.

@p3x-robot

This comment has been minimized.

Show comment
Hide comment
@p3x-robot

p3x-robot May 26, 2017

is it possible to set the cron in .travis.yml?

is it possible to set the cron in .travis.yml?

@aakritigupta

This comment has been minimized.

Show comment
Hide comment
@aakritigupta

aakritigupta May 29, 2017

@jeljaik

Is there any way I can set up a "custom Cron job" that triggers the build of my repository based on the commits made in a different repo?

No :)

@jeljaik

Is there any way I can set up a "custom Cron job" that triggers the build of my repository based on the commits made in a different repo?

No :)

@aakritigupta

This comment has been minimized.

Show comment
Hide comment
@aakritigupta

aakritigupta May 29, 2017

@jd-gascuel

Sounds great.
But I have a bug: If I try to add a cron on a specific branch, it insists to do it on master instead...

Could you write to us at support@travis-ci.com with more information about the repo? We'll get back to you there :)

@jd-gascuel

Sounds great.
But I have a bug: If I try to add a cron on a specific branch, it insists to do it on master instead...

Could you write to us at support@travis-ci.com with more information about the repo? We'll get back to you there :)

@aakritigupta

This comment has been minimized.

Show comment
Hide comment
@aakritigupta

aakritigupta May 29, 2017

@ christophermaier

Very useful feature; however, I've noticed that repositories that were running cron jobs daily (and set to Always run) have stopped running recently. On the Settings page, the cron widget will say that a job ran, say, 3 hours ago, but no build has really run in several days. Removing and recreating the cron job has no effect. Some of my repositories continue to run cron jobs like normal, though, so I'm not quite clear on what's happening.

Please write to us at support@travis-ci.com with more information about the repo and we'll get back to you :)

@ christophermaier

Very useful feature; however, I've noticed that repositories that were running cron jobs daily (and set to Always run) have stopped running recently. On the Settings page, the cron widget will say that a job ran, say, 3 hours ago, but no build has really run in several days. Removing and recreating the cron job has no effect. Some of my repositories continue to run cron jobs like normal, though, so I'm not quite clear on what's happening.

Please write to us at support@travis-ci.com with more information about the repo and we'll get back to you :)

@aakritigupta

This comment has been minimized.

Show comment
Hide comment
@aakritigupta

aakritigupta May 29, 2017

@p3x-robot

is it possible to set the cron in .travis.yml?

No, you need to set it through the UI :)

@p3x-robot

is it possible to set the cron in .travis.yml?

No, you need to set it through the UI :)

@aakritigupta

This comment has been minimized.

Show comment
Hide comment
@aakritigupta

aakritigupta May 29, 2017

Thanks for the suggestion everyone! We're working on getting crons out of Beta with some of the suggestions mentioned above. :)

Thanks for the suggestion everyone! We're working on getting crons out of Beta with some of the suggestions mentioned above. :)

@jeremylong

This comment has been minimized.

Show comment
Hide comment
@jeremylong

jeremylong Jun 2, 2017

This may not be the right place to ask this question - but I'll start here as it relates to crons. I am trying to figure out how I could setup a Coverity scan on my master branch monthly. Is it possible in YAML to conditionally include addons based on the TRAVIS_EVENT_TYPE?

This may not be the right place to ask this question - but I'll start here as it relates to crons. I am trying to figure out how I could setup a Coverity scan on my master branch monthly. Is it possible in YAML to conditionally include addons based on the TRAVIS_EVENT_TYPE?

@krzycz

This comment has been minimized.

Show comment
Hide comment
@krzycz

krzycz Jun 2, 2017

@jeremylong - please, take a look at https://github.com/pmem/nvml repo. We do the daily Coverity scans using crons.

krzycz commented Jun 2, 2017

@jeremylong - please, take a look at https://github.com/pmem/nvml repo. We do the daily Coverity scans using crons.

@jeremylong

This comment has been minimized.

Show comment
Hide comment
@jeremylong

jeremylong Jun 3, 2017

@krzycz thanks! I was hoping to use the addon instead of scripting the coverity scan - but the script route works.

@krzycz thanks! I was hoping to use the addon instead of scripting the coverity scan - but the script route works.

@psy0rz

This comment has been minimized.

Show comment
Hide comment
@psy0rz

psy0rz Jun 10, 2017

is it possible to use this feature to build nightlys and release them on github?

preferable with customized build paramters so that we can skip a lot of checks and extra binary's.

psy0rz commented Jun 10, 2017

is it possible to use this feature to build nightlys and release them on github?

preferable with customized build paramters so that we can skip a lot of checks and extra binary's.

@phil-davis

This comment has been minimized.

Show comment
Hide comment
@phil-davis

phil-davis Jun 10, 2017

@psy0rz you can do anything that you could do in a normal Travis build matrix of jobs that runs from PRs or changes on master. You can check the TRAVIS_EVENT_TYPE environment variable to know if you are running from cron, and so you can make conditional checks to do more or less or different things in the cron job, as you wish.

@psy0rz you can do anything that you could do in a normal Travis build matrix of jobs that runs from PRs or changes on master. You can check the TRAVIS_EVENT_TYPE environment variable to know if you are running from cron, and so you can make conditional checks to do more or less or different things in the cron job, as you wish.

@lrascao

This comment has been minimized.

Show comment
Hide comment
@lrascao

lrascao Jun 11, 2017

@psy0rz @phil-davis the only thing missing to make this really work is per-cron job environment variables, a typical use-case is having two nightly cron jobs, one with the latest changes in the project and another with the latest changes in the project + latest changes in dependencies.

lrascao commented Jun 11, 2017

@psy0rz @phil-davis the only thing missing to make this really work is per-cron job environment variables, a typical use-case is having two nightly cron jobs, one with the latest changes in the project and another with the latest changes in the project + latest changes in dependencies.

@Andretalik

This comment has been minimized.

Show comment
Hide comment
@Andretalik

Andretalik Jun 14, 2017

Its a nice feature. Loving it so far. The only problem I think it has in my scope and opinion is that the job moves forward everyday by a minute.
So may be if its a large scale project and like 3 months down the line the update time of the cron would have substantially shifted. Maybe if you could set a static time for the cron to run

Its a nice feature. Loving it so far. The only problem I think it has in my scope and opinion is that the job moves forward everyday by a minute.
So may be if its a large scale project and like 3 months down the line the update time of the cron would have substantially shifted. Maybe if you could set a static time for the cron to run

@eltonlauhk01

This comment has been minimized.

Show comment
Hide comment
@eltonlauhk01

eltonlauhk01 Jun 15, 2017

please support user defined cron rule

please support user defined cron rule

@thislooksfun

This comment has been minimized.

Show comment
Hide comment
@thislooksfun

thislooksfun Jun 21, 2017

The branch select seems to ignore the selection for me. It defaulted to "core", which was correct, but then when I clicked "add", the resulting cron job said "master".

The branch select seems to ignore the selection for me. It defaulted to "core", which was correct, but then when I clicked "add", the resulting cron job said "master".

@igorwwwwwwwwwwwwwwwwwwww

This comment has been minimized.

Show comment
Hide comment
@igorwwwwwwwwwwwwwwwwwwww

igorwwwwwwwwwwwwwwwwwwww Jun 21, 2017

@thislooksfun thanks for the report, it may be related to live updating of the branches dropdown when a new branch is pushed. could you let me know which browser (and version) you experienced this with? thank you!

@thislooksfun thanks for the report, it may be related to live updating of the branches dropdown when a new branch is pushed. could you let me know which browser (and version) you experienced this with? thank you!

@aakritigupta

This comment has been minimized.

Show comment
Hide comment
@aakritigupta

aakritigupta Jun 21, 2017

@thislooksfun feel free to write to us at support@travis-ci.com with that information.

@thislooksfun feel free to write to us at support@travis-ci.com with that information.

@aakritigupta

This comment has been minimized.

Show comment
Hide comment
@aakritigupta

aakritigupta Jun 21, 2017

Hi all!
We've just promoted Crons out of Beta with the first round of fixes as discussed earlier in the thread.

Thank you all for participating. We'll keep the rest of the suggestions in mind as we work on future improvements. I am closing this thread.

If you have more feedback to give us, please drop us a line at support@travis-ci.com :)

🎉

Hi all!
We've just promoted Crons out of Beta with the first round of fixes as discussed earlier in the thread.

Thank you all for participating. We'll keep the rest of the suggestions in mind as we work on future improvements. I am closing this thread.

If you have more feedback to give us, please drop us a line at support@travis-ci.com :)

🎉

@bfred-it bfred-it referenced this issue Jul 8, 2017

Closed

Versioning, deployment improvements #595

1 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment