I'd like to be able to stop build for some build definitions programmatically.
First I thought about creating some event handler (soap service or TFS plugin) to solve this issue. But unfortunatelly it seems like there isn't appropriate event in TFS (that would be raised when build is just started).
Is there the way to solve this issue?
Thank you!
Elena
Upd:
The problem has been solved by call of cutom build task in the very first target in TFSBuild.proj
Most build monitors seem to periodically poll TFS to see if there's any new builds, this obviously won't work for you as there will be too much of a delay to cancel the build.
I suggest you modify the build template to do a web request right at the start. Or just putting the logic to cancel the build in the actual template.
May i ask why you need to cancel builds anyway? there may be a better alternative.
Related
When some of my GithubActions jobs has failed, I don't have the possibility to re-run the specific failing job, only "Re-run all jobs". Is there any way to achieve this?
This is all working now in GitHub, the caveat is you can only run "specific jobs in a workflow run up to 30 days after its initial run."
https://docs.github.com/en/actions/managing-workflow-runs/re-running-workflows-and-jobs#reviewing-previous-workflow-runs
I’m the workflow file you want to be able to manually trigger, add workflow_dispatch to the “on:” clause. Then go to the actions tab on github, select the action and you should see the option to manually run it. Before asking this type of question, please use google next time. When looking for “triggger github workflow manually” the first result is a article written by github on how to do it. https://docs.github.com/en/actions/managing-workflow-runs/manually-running-a-workflow
Unfortunately, re-run a single job is not possible yet.
Their repository does have an Open Issue to implement this feature.
https://github.com/actions/runner/issues/432
The good news is it is officially in their roadmap and is scheduled for Q1 2022.
https://github.com/github/roadmap/issues/271
In tfs when automatic release occurs (each night) my team have to change their backlogitems asociated with this build to an state called 'ready for qa' next day, sometimes we forget it, if the build mark those backlogitems as 'ready for qa' when it's success it would be great. Is there a way to configure the automatic release to do that?
I don't believe there is any native way to do this, but the following extension Update Work Item in the VSTS marketplace should work for you.
After installing the extension, you will need to add a task to your Release Definition and configure it to suit your needs. Be sure to enable the "Allow Scripts to Access OAuth Token" setting in your release.
Note: there are some nuances in configuring this task to be sure to read all of the 'help' icons during initial configuration
Personally, I found using TFS Rest API as a good way of updating Work items. The Work items update TFS API is quite simple and easy to use
https://www.visualstudio.com/en-us/docs/integrate/api/wit/updates
The advantage of using it over build task is that you can run and test it locally and is easier to update and maintain
I currently have hundreds of builds in the build queue. It will take several days for them all to be built.
I want to bring a specific build to the front of the queue to have it build next.
Currently, the only way I have of doing that is to kill all of the other jobs in the build queue and then re-trigger them.
It seems that surely there must be a better way.
Is there?
Looks like there is no such built-in functionality.
Please, have a look at the jira issue: Ability to move job to top of queue
Although, there is a plugin which seems like a possible solution for you: Accelerated Build Now Plugin
The Jenkins Accelerated Build Now Plugin allows Jenkins users to launch a project's build right away, even if the queue is long (moving it to the top of the queue) and even if no executor is available (killing and rescheduling builds not launched by "humans")
Maybe this plugin will help you : https://wiki.jenkins-ci.org/display/JENKINS/Accelerated+Build+Now+Plugin
https://plugins.jenkins.io/simple-queue/ is a plugin that allows changing a build queue order from UI manually. And it seems to be a viable solution in 2022.
Here is my situation.
I setup a build definition for continuous integration using the new workflow system. Then I targeted this definition to a particular solution. I checked-in my solution many times without a problem and the builds have all passed flawlessly on the server.
This morning, I notice that it has been executed but I did not checked-in the solution. I finally discover that when a colleague checked-in another solution, it executed the definition for the solution I am working on.
I am using the original ProcessTemplate.xaml file. I only want this build definition to be executed when I check-in a particular solution or a set of solution I chose. What do I miss here?
Thanks.
There are two things you need to do,
1. Edit build defination and click on the process tab, change the 'Items to Build' to the solution that you are interested to be build as part of your build.
2. Click on the workspace tab and point it only to the branch or specifically to the folder which logically excludes the solutions that you would like to exlude from this ci build.
Make sure you carry these steps across your build definations.
HTH.
Cheers, Tarun
I am trying to setup a gated check-in policy, but I am running into an issue with my workflow.
In the build definition menu, I select Trigger -> Gated Check-in.
This gives me the error...
"The trigger you selected in the trigger tab cannot be used with the Build Process template you specified on the process tab. (It supports the build reasons Manual, IndividualCI, BatchedCI, Scheduled, ScheduleForced, UserCreated)"
Anyone have an idea as to where I can select which build reasons it supports?
I looked through all the code in the .xaml file, but I did not see anything that stood out as being the issue.
Any help here would be greatly appreciated.
The Build Workflow has an argument called SupportedReasons that usually has a default value set. Try changing the default value of this argument.
I solved this by pasting the contents of this xaml file into an existing xaml file that I knew could be used as a Gated Check-in template.
I don't know what the difference is, but this did the trick.