So I inherited a slightly odd setup (Changing it will be time consuming):
I am using Jenkins with SCM (Perforce) polling, but the triggered job does not use the SCM Workspace in any way except the triggering itself. Then the build pulls the latest revision and builds from that. This setup works, but it creates an unnecessary backlog:
10:00 submit Rev#100001
10:05 SCM polls this and queue a build job#101
10:06 job#101 start (will take ~2H)
10:30 submit Rev#100002
10:35 SCM polls this and queue a build job#102
11:00 submit Rev#100003
11:35 SCM polls this and queue a build job#103
12:00 job#101 exits
12:01 job#102 start (will take ~2H)
Now assuming no new submits, job#103 is an unneeded repeat of job#102.
Update: From #Slav's answer I realized that I was not clear enough. The fact that the SCM trigger is not related to the pulling of the code base, cause this abnormality:
job#101 reports that it was triggered by Rev#100001 and builds from Rev#100001
job#102 reports that it was triggered by Rev#100002 and builds from Rev#100003
job#103 reports that it was triggered by Rev#100003 and builds from Rev#100003
This also explains why there are more then one queued run: From Jenkins'es POV, each queued build is different.
I wish to eliminate this backlog.
This can be done by e.g.
When job#101 is running don't poll SCM (best option)
When job#103 is queued - remove job#102 if it didn't started yet.
any other way?
Is this possible? And if so how?
Are you sure this is happening? I've never seen more than 1 queued run, even if there are multiple triggers in between.
When I had scenarios where a build was taking longer than the polling interval, easiest way to manually fix it is by disabling the job after it had started (and re-enabling it after it completed), but that's only useful in case of exceptions and manual intervention.
If you want this for automation purposes, you should look at "quiet period" advanced options (under Job Configuraiton).
Related
I want to run a Veracode security scan on our big application. The problem is that the scan takes about 5 days and I do not want to keep the pipeline agent pinned down during all this time.
My current solution is this:
Have build 1 to upload the binaries and initiate the pre-scan.
Have build 2 run automatically when build 1 is over and poll the status of the upload. If the pre-scan is over - start the scan. If the scan is over - mark as success and clear the schedule. If the pre-scan or scan is still running - schedule the build 2 to run every 30 minutes from the current point in time by modifying the schedule in the build definition and mark the build as partially succeeded.
This scheme works, but I wonder if it can be simplified.
What if the build 2 was a Release tied to the build 1?
But is it possible to repeat the logic without scheduling a new Release every time and without pinning down the build agent for the entire duration of the scan (5 days) and by using YAML (i.e. unified pipeline instead of Build + Release) ?
After all, a single Release is able to deploy the same stage mutliple times - these are the different deployment attempts. The problem is that I do not know how to request an attempt in 30 minutes without just blocking the agent for the next 30 minutes, which is unacceptable.
So this brings up the question - can we use a YAML pipeline to start a build and then poll a third party service until it returns what we need (the payload must be parsed and examined, HTTP Status code is not enough) so that the next stage could run?
You're looking for the concept of "gates" or "approvals and checks" depending on whether you're using YAML or classic pipelines.
You can add an "invoke REST API" check that periodically queries a REST endpoint and only proceeds when it satisfies the necessary conditions. This is a "serverless" operation -- it does not tie up an agent.
Currently we are using Github Actions for CI for infrastructure.
Infrastructure is using terraform and a code change on a module triggers plan and deploy for changed module only (hence only updates related modules, e.g 1 pod container)
Since auto-update can be triggered by another github repository push they can come relatively on same time frame, e.g Pod A Image is updated and Pod B Image is updated.
Without any concurrency in place, since terraform holds lock, one of the actions will fail due to lock timeout.
After implementing concurreny it is ok for just 2 on same time pushes to deploy as second one can wait for first one to finish.
Yet if there are more coming, Githubs concurreny only takes into account last push for queue and cancels waiting ones (in progress one can still continue). This is logical from single app domain perspective but since our Infra code is using difference checks, by passing deployments on canceled job actually bypasses and deployment!.
Is there a mechanism where we can queue workflows (or even maybe give a queue wait timeout) on Github Actions ?
Eventually we wrote our own script in workflow to wait for previous runs
Get information on current run
Collect previous non completed runs
and wait until completed (in a loop)
If exited waiting loop continue
on workflow
Tutorial on checking status of workflow jobs
https://www.softwaretester.blog/detecting-github-workflow-job-run-status-changes
We have an issue where currently we have a single release running and one release queued. Normally this would be ok, but we run self-hosted agents and have currently 9 agents sitting idle to run the release. I keep seeing parallel jobs, but I don't know if that solves this, as this feels more like something that I have misconfigured.
Since this post we have purchased 10 parallel jobs for the self-hosted pool and still are seeing this issue.
In your current situation, we recommend you can try to check your Deployment queue settings, this setting is used to configure actions when multiple releases are queued for deployment. You can select the 'Unlimited':
Hi I'm running batch jobs via SCDF in openshift environment. All the jobs have been scheduled through the scheduling option in SCDF. Is there way to pause or Hold those jobs from executing instead of destroying the schedules ? Since the number of jobs are more, everytime we have to recreated the schedules for all of them.
Thanks.
We have an open issue: spring-cloud/spring-cloud-dataflow#3276 to add support for it.
Feel free to update the issue with your use-case requirements and the acceptance criteria. Better yet, it'd be great if you can contribute adding support for it in a PR; we would love to collaborate and release it.
My requirement is:
Workflow should run daily at 2pm. Workflow has been scheduled to run at 2pm
We have lookup on master tables. Records with IDs that are not present in the master tables will get rejected.
These new IDs have to be loaded into the master tables manually and then the workflow has to be re-run.
Daily the same thing happens.
My question is -
Is it possible to schedule a workflow to run twice every day(one for the first run, the other to run after the master table is updated)?
If No, can I manually start a scheduled workflow? Will it make the workflow unscheduled?
Please, Can any one help me with this?
Informatica's scheduler is a weak spot. I guess using two copies of the same workflow with different schedules would be the easiest solution.
Got a solution for my problem.
Once a workflow is scheduled, even if a particular session has to be re-run manually, whole workflow has be run from the workflow manager.
If that particular session is run manually, scheduling will be gone.
So always run the workflow instead of a session, so that scheduling will remain.