How to add the views in pipeline script to run the views parallelly. I have different views like
EX: view name: Project A --> Project A consists of different jobs like job1, job2,...etc
view name: Project B--> Project B consists of different jobs like B1, B2,...etc.
I have to create a pipeline when i trigger the build it has to run the both the views (project A and Project B) parallelly and completes all the builds within short time.
Please help.
Related
I have a Laravel project in Azure App Service ..
I'm using Laravel queue to run long jobs in the background, so I've added a WebJob to run the queue .. the problem is the jobs execute sequentially and not parallelly.
After searching I found that I need a supervisor to run multiple workers.
My question is how can I run multiple workers to run the same queue in Azure??
My continuous WebJob:
php %HOME%\site\wwwroot\artisan queue:listen --timeout=0
Based on my understand of the issue. Continuous Job runs on all instances that the web app runs on. Indeed, you can optionally restrict the WebJob to a single instance (different in your case).
Note that App Service will only look for a script under the root directory of that job (not under sub directories of it). Only these are supported file types for scripts or programs are listed here:
Laravel, uses the public/ subdirectory as the site root.
Jobs are deployed by copying them to d:\home\site\wwwroot as illustrated below. These Jobs will run under the worker process of the SCM\Kudu Web Site and not the main site.
Path : wwwroot\app_data\jobs\continuous{job name}).
To set a continuous job as singleton during deployment then you can simply create a file called settings.job with the content: { "is_singleton": true } and put it at the root of the (specific) WebJob directory. However, in your case { "is_singleton": false }
If your requirement fits you can use WebJobs API or Azure Functions
Currently, the project is using v2 of circleCI and it doesn't have any workflows, just 1 job.
I want to create 2 workflows(one is the old job and one is the new one for my integration tests) in config.yml file, but I want the first job to run with each commit and the second one to run only once daily
Is it possible to do?
Yes. Create one regular Workflow and one Scheduled Workflow. The former will run on commit while the former would run on a cron. https://circleci.com/docs/2.0/workflows/#scheduling-a-workflow
We have a teamcity set-up on with multiple agents. There is one particular build which uses some underlying resources and services of a particular environment. ( say uat)
We want that this build should not run n parallel to avoid resource contention. i.e. only a single running build at a time. How can I achieve this ?
Thanks
Under the project, setup a shared resource:
Then under the build configurations you don't wish to be able to run in parallel add a build feature and select the resource you just created and "Write Lock":
This will mean any extra builds triggered will stay in the build queue and will not be allowed to run concurrently.
VSTS allows you to select which branches automatically trigger a CI build by specifying a branch pattern.
However, my unit tests are using a real database which causes a problem when more than one build triggers e.g. master and feature-123 as they will clash on the database tests.
Is there a way of specifying that only one such build should be run at at time; I don't want to go away from executing tests against a real database as there are significant differences between an in-memory database and SQL Azure.
VSTS already serialize builds which are triggered by the same CI build.
Even CI build can be triggered by multiple branches, but for a certain time, only one build is running by default (unless you use pipelines to run builds concurrently).
Such as if both master branch and feature-123 branch are pushed to remote repo at the time time, the CI build definition will trriger two builds serially (not concurrently).
If you are using pipeline and need to run the triggered builds serially, you should make sure only one agent is used for the CI builds. You can use the way below:
In your CI build definition -> Options Tab -> add demands to specify which agent you want to use for the CI build.
Assume in default agent pool, there are three agents with the agent name: default1, default2 and default3.
If you need to specify default2 agent to run the CI build, then you can add the demands as below:
Now even multiple branches have been pushed at the same time, they will be triggered one by one since only one agent is available for the CI build.
If you use a YAML pipeline, you can use a deployment job in stead of a regular job.
With a deployment job you select a named Environment you want to deploy to.
You can configure the Environment in azure devops under Pipelines->Environments and you can choose to add an Exclusive Lock.
Then only one run can use the environment at a time and this serializes your runs.
Unfortunately, if you have multiple runs waiting for the environment (because one run currently has it locked), when the environment becomes unlocked only the latest run will continue. All the others waiting for the lock will be cancelled.
If you want to do it via .yml or .yaml file you can do following
- phase: Build
queue:
name: <Agent pool name>
demands:
- agent.name -equals <agent name from agent pool>
steps:
- task: <taskname>
displayName: 'some display name'
inputs:
value: '<input variable based on type of task'
variableName: '<input variable name>'
I don't want Build Config A and Build Config B to run at the same time. This is because they share the same resource which cannot be accessed simultaneously. However each build config is run by a separate agent so it is possible for them to run simultaneously.
Instead I would like one build config, when triggered, to wait for the other to finish if it is running. For example if Build Config B begins to run but Build Config A is already running, then B would wait until A finishes and then B would run.
I don't think a snapshot dependency will work because that assumes one config has a dependency on the other which is not true in my case.
Keith, there are two plugins that can help you:
The first one is Groovy plugin. It has functionality of creating name locks over all projects.
The second one is TeamCity.SharedResources. It has functionality of definig shared resources and locking them with read and write locks. However, resources defined in this plugin, are are defined per-project. We are actively developing this plugin, so you are welcome to watch its page in our tracker
For a quick and dirty, just make a rule on the compatible agents tab for the project. That they have to run on the agent name containing xxx ( whatever that is ) then those builds can only run on that agent and will never run at the same time.
In the newest version of TeamCity, you can configure this parameter. Go to the Edit Configuration Settings -> Edit Configuration Settings and set parametr:
Limit the number of simultaneously running builds (0 — unlimited)