In the Zapier documentation, it says:
Code Steps are limited to 75 runs every 10 seconds.
Is this a limit that applies account wide, or is it per zap/task/code step?
Account wide: If I have 76 different zaps that get triggered at the same time (from different sources within the same 10 seconds), and each one contains a code step, would the 76th zap fail?
Per task/code step: If I have a zap (containing a code step) which gets triggered 76 times within the same 10 seconds, would the 76th invocation fail?
Per zap: If I run a single zap with 76 rapid code steps (under 10 seconds), would it fail on the 76th one?
Related
I made a simple program which waits for 60 seconds. I have 300 input elements to process.
Number of threads - Batch - 1 and Streaming - 300 per this document
https://cloud.google.com/dataflow/docs/resources/faq#beam-java-sdk
In streaming mode - with 1 worker and 300 threads, job should complete in 2 to 3 minutes considering the overhead of spawning workers etc. My understanding is there will be 300 threads for each of 300 input elements and all sleep for 60 seconds and the job should get done. However, the job takes more time to complete.
Similarly, in Batch mode with 1 worker (1 Thread) and 300 input elements, it should take 300 minutes to complete.
Can someone clarify how this happens at worker level ?
There is considerable overhead in starting up and tearing down worker VMs, so it's hard to generalize from a short experiment such as this. In addition, there's not promise that there will be a given number of workers for streaming or batch, as this is an implementation-dependent parameter that my change at any time for any runner (and indeed may even be chosen dynamically).
I have a job and it can run concurrently. The trick part here is that this job needs to have an interval to one another, at least for 30 seconds. So when Build1 runs, Build2 should wait for 30 seconds to start.
I already tried using the quiet period but it does not fit my needs (it only works when a job is not triggered by Build Now or Build With Parameters)
Is there a way for me to be able to do this kind of condition?
You can try enumerating other builds of this job and sleeping until all the other builds have been running above 30 seconds. See example code in this answer.
Let's say i have repo which for each push (build) starts 4 jobs (diffrent environment/compilers etc.).
There is time limit for builds - 50min. Is it counted as sum of times of all builds (like in left panel), or is it independant for each job?
Example: 4 builds, each taking 20minute - will it timeout becouse it will be counter as 80min or will it be ok and count as 20min (time of longest job)?
The Travis CI documentation is pretty clear about this. A build consists of one or many jobs. The limit is enforced for each job:
There is no timeout for a build; a build will run as long as all the jobs do as long as each job does not timeout.
For example, the current timeout for a job on travis-ci.org is 50 minutes (and at least one line printed to stdout/stderr per 10 minutes).
I have a job that kicks off on any commit. It takes 5-10 minutes to run.
But if (say) 4 or 5 git commits come back-to-back I don't want 4 or 5 jobs run - just one job for the last commit. So basically if there is a job of type "X" in the build queue I don't want another job of type "X" in the queue.
That should be the default behavior if you're using the SCM trigger, default job parameters, and don't check the 'Execute concurrent builds if necessary' option.
First job is going to queue and run immediately.
On source change, next job is going to queue and wait until first one is complete.
A third SCM change would detect job already in queue and not do anything.
When first job is done, next one will start - and will use whatever is in the SCM at the moment it starts (not the moment it was scheduled).
That behavior can be changed using parameters, concurrent builds, job throttling, etc. My knowledge there might also be outdated (Jenkins is evolving pretty fast).
On a side note: multiple builds are not necessarily a bad thing - they give you failure locality, which might allow you faster identification of the offending commit. It doesn't matter much for 10 minutes builds, but if your build grows larger than that it can be a problem (with a large team, you can have a LOT of commits in 30 minutes).
Basically you just want to check if there is a new commit every 5 or 10 minutes? You can do that inside the triggering configuration: monitor source control every X minutes (CRON syntax: */15 * * * * for every 15mins)
If you check every 15 minutes if a new commit happened and your jobs only takes 10 minutes to run, there is no chance you would have another execution pending (unless someone ask for a "manual" construction...).
To avoid the latter case, you may consider the Throttle Concurrent Builds plugin
I have a script that I have to run every 10 minutes but only during say 1AM - 2AM Local time.
Long story short; the script updates about 80+ internal Google Spreadsheets but it must only do this during the hours mentioned above so the chance of a user being in a spreadsheet doing work at the time is almost zero.
I've looked at the Time-Driven Triggers and it has both the functions (to run every 10 minutes and also to run between 1am-2am) however I need to fuse these two triggers together.
Is this possible?