We are currently in the process of migrating our CI/CD pipelines to GitLab. For testing purposes we are using a runner deployed on OpenShift 4 using the GitLab Runner operator. Using the default configuration for now (we are still in a very early stage) we are able to spin up runners normally and without issues, however we are noticing long delays between jobs. For example a build job normally takes about 2 minutes for the actual build to take place, takes almost 8 minutes in total as a job to finish. This happens even after the job has successfully finished (as evident by the logs). This in turn means that there are long delays between jobs of a single pipeline.
I took a look at the configuration properties of the runner but I am unable to figure out whether we have something misconfigured. For reference we are using GitLab CE version 13.12.15 and the Runner in question is running version 15.0.0.
Does anyone know how to mitigate this problem?
I have an Azure webjob created using the SDK that runs hourly. The job runs, and works fine, but when I look at the job in the portal it always shows Failed. I can run the job from the Debug Console and everything appears fine. When run from the console the job typically takes seconds to run, but when run on the schedule it usually shows 12-20 minutes, before it fails.
How can I get more details as to why this is failing? Do I need to be telling webjobs somehow the task is finished and it's waiting on me?
Thanks,
Russ
Webjob Failure
This error happens if the job uses TimerTrigger.
If the job is long-running use WEBJOBS_IDLE_TIMEOUT and SCM_COMMAND_IDLE_TIMEOUT in Azure app settings instead of web.config.
If the job is not long-running, it should have scheduled timers less than 2 minutes, which will probably work well for testing only.
Finally, the ultimate solution is to use Basic or Standard offering of AppPlan.
In that case you can ENABLE Always On to keep the container loaded all the time.
However, WEBJOBS_IDLE_TIMEOUT and SCM_COMMAND_IDLE_TIMEOUT must also be set as described above. Continuous WebJobs or of WebJobs triggered using a CRON (TimerTrigger) expression without Always On, will not run reliably.
For more details, you could refer to this article.
I have two pipelines (also called "build definitions") in azure pipelines, one is executing system tests and one is executing performance tests. Both are using the same test environment. I have to make sure that the performance pipeline is not triggered when the system test pipeline is running and vice versa.
What I've tried so far: I can access the Azure DevOps REST-API to check whether a build is running for a certain definition. So it would be possible for me to implement a job executing a script before the actual pipeline runs. The script then just checks for the build status of the other pipeline by checking the REST-API each second and times out after e.g. 1 hour.
However, this seems quite hacky to me. Is there a better way to block a build pipeline while another one is running?
If your project is private, the Microsoft-hosted CI/CD parallel job limit is one free parallel job that can run for up to 60 minutes each time, until you've used 1,800 minutes (30 hours) per month.
The self-hosted CI/CD parallel job limit is one self-hosted parallel job. Additionally, for each active Visual Studio Enterprise subscriber who is a member of your organization, you get one additional self-hosted parallel job.
And now, there isn't such setting to control different agent pool parallel job limit.But there is a similar problem on the community, and the answer has been marked. I recommend you can check if the answer is helpful for you. Here is the link.
I have a Scheduled Azure WebJob which runs every 5 mins. It's not clear what happens if the running times takes 10 mins. Is a new one started parallel to the one still running, or is it not started until the previous one has finished?
From this answer What happens when a scheduled WebJob runs for a long time :
As i understand it scheduled webjobs is just triggered webjobs that is run using Azure Scheduler, if you open Azure Scheduler in management portal you can see the webjobs and even configure them in more detail. (You can see the log too which would give you the simple answer to your question).
If you like to look at whats going on your scheduled webjob is run as a Triggered webjob by Kudu, if you look in the Kudu source you will see that a lockfile is created when a job is started, and if you try to start another job a ConflictException is thrown if there is already a lock file.
The Azure scheduler calls your job using a webhook that catches the ConflictException and gives you the "Error_WebJobAlreadyRunning" warning which will tell you: "Cannot start a new run since job is already running."
I've seen that Heroku charges $15/mo to run Delayed Job, and $3/mo to run cron tasks daily. Is it possible to skip that entirely and run my own cron tasks manually? Or are they somehow figuring out that I'm running cron tasks?
I'm not entirely sure what you mean by "run my own cron tasks manually". For cron specifically, you need access to crontab, which they can control, as they're their servers. If you have another way of doing it, it would probably be fine, but bear in mind that your app is not tied to a specific server when running under Heroku, and that the server will change between executions.
Also, unless they've changed it since last time I checked, you can run daily cron tasks for free, but hourly costs $3/mo.
EDIT: Yes, daily crons are free. See http://addons.heroku.com/.
If you install the Heroku gem on your computer, you can then run your cron tasks manually as follows:
$ heroku rake cron
(in /disk1/home/slugs/xxxxxx_aa515b2_6c4f/mnt)
Running cron at 2010/04/25 10:28:54...
This will execute the exact same code as Heroku's daily/hourly cron add-on does; that is, for this to work, your application must have a Rakefile with a cron task, for example:
desc "Runs cron maintenance tasks."
task :cron do
puts "Running cron at #{Time.now.strftime('%Y/%m/%d %H:%M:%S')}..."
# TODO: your cron code goes here
end
Now, just add the heroku rake cron command to a crontab on any Unix server of yours, or even directly to your personal computer's crontab if you're running Linux or Mac OS X, and you can be scheduling cron jobs for your Heroku application as you please and without being charged for it.
Updating the answer for 2020:
You can use Heroku Scheduler which is Heroku's own add-on that lets you schedule commands using one-off dynos (so that you only pay for the run time of your jobs). The add-on itself is free, but doesn't really allow you to use cron but rather plain frequency: every day, every hour or every 10 minutes. Also, there's no guarantee that your job will execute at the scheduled time or at all..
There are other 3rd party add-ons that can help you run one-off dynos using cron expressions for better flexibility and are more resilient than Heroku Scheduler (proper disclosure, my company is the creator of one such add-on).
You can also use custom clock process (see here for more info) which essentially means that you have one dyno or process spawn tasks that run on other dynos. This usually costs more than using the aforementioned add-ons, but you have more granular control over your processes and since you only rely on Heroku, it may be more stable.
Yes, I've successfully used a cron job on my local server which essentially runs
$ heroku rake <rake task>
at whatever intervals I've required. I've used in on both aspen and bamboo stacks.
You can also just install a gem like rufus-scheduler if you're running a rails app and setup scheduling that way. I don't know if this is bad practice for some reason, but it's what I do with my app, and it seems to work fine.
If you want to have scheduled jobs you can also use http://guardiano.getpeople.in that is a free service (for 10 jobs) for job scheduling.
You just need to setup an HTTP endpoint in your application to recieve event notifications on POST or GET and you can also set some additional params to prevent not authorized actions.
So you set a job in Guardiano that will cal http://yourapp.com/youraction and leave "minutes" blank if you want you action to run once in the future or set minutes to what you want to run your action every X minutes. In that way you only have to create your endpoint for you app and when this EP is called you execute something.
So your app can sleep and you don't need to spend money and time setting up jobs and taking care that they are working properly.
IMHO if you need something fast for an MVP or you need to setup a lot of jobs for different apps than a free service like that where you can actually outsource cronjobs is quite good.
There was aslo an Heroku Addon called Temporize to do that but I'm not sure is still alive and working