We are building a custom Visual Studio build task to implement compliance validation of the builds defined by our developper teams.
The objective is to mark builds using "unauthorized" tasks, or failing to use mandatory tasks in a way that will be possible for a BuildCompleted servicehook to act upon later on.
We are creating a JSON structure describing the different business rules we want to enforce, and we have a service hook catching end-of-build events to create a tracability file that will mark the build artifacts as "deployable" or not.
I can see from the MS references that a Issue collection is returned with the GetBuildDetails responss that seems to list exactly the kind of information we'd like to pass along.
Anyone found a way to populate that property?
Thanks!
The solution is add additional information to the build result by using Logging Commands (e.g. ##vso[task.logissue]error/warning message)
Related
I have an pipeline which will have few task mentioned in the image. I'm creating a bug work item when a particular task failed which is working fine using logic app.
Now my problem is I don't want to add every time new task for bug creation after each deployment task mentioned in the image.
Is there any way I can create only one bug work item based on failure in any of the task in the pipeline. may be in the last or somewhere..?
Not sure why you had to go the Logic app route as there is an option to do this with Azure Pipelines itself out of the box.
Navigate to {your pipeline} > Options as shown below:
If the build pipeline fails, you can automatically create a work item to track getting the problem fixed. You can specify the work item type. You can also select if you want to assign the work item to the requestor. For example, if this is a CI build, and a team member checks in some code that breaks the build, then the work item is assigned to that person.
Additional Fields: You can also set the value of other work item fields. For example:
Field Value
------- -------
System.Title Build $(Build.BuildNumber) failed
System.Reason Build failure
Check Build Options for more details.
UPDATE:
Doing this for Release Pipelines is not supported as an out of the box feature as of today. However, there are extensions available in the Visual Studio marketplace that can be used as alternatives until it is supported.
Here are two such extensions:
Create Bug on Release failure
Create Work Item
Another idea with PowerShell tasks is discussed here.
I'm wanting to add some test case attachments during a build or release but I'm struggling to find a valid approach to do this. I'm not using MSTest.
I tried creating a custom build/release task but I've found the azure-devops-node-api package to be flaky at best, and seemingly lacking contributors.
This is what I would hope to do...
Use C# if possible
Have the code/task available for either a build or release across multiple repositories and projects (same organization) without code duplication
Automatically authenticate with the currently running build/release without needing PAT tokens or any other form of authentication
Access to both Azure File Storage and Azure Devops
Works with any build or release agent
Is this achievable? I've seen odd articles in various places but nothing like whats described above. For example this shows promise in terms of validating the current build/release in a C# application however it is 4 years old now and doesn't explain how to integrate with a pipeline.
Can anyone help?
Thanks,
I've always leveraged mstest, so within the runner we've had access in c# to the TestContext that supports adding the attachements directly to the test result.
It looks like the API is exposed for adding attachments to the runs though, so I would think you can create something either in c# or in powershell that accomplishes what you are asking. You will likely need to make sure the agent phase has access to the OAuth token.
POST https://dev.azure.com/{organization}/{project}/_apis/test/Runs/{runId}/Results/{testCaseResultId}/attachments?api-version=5.1-preview.1
I have a build up on Azure Pipelines, and one of the steps provides a code metric that I would like to have be consumable after the build is done. Ideally, this would be in the form of a badge like this (where we have text on the left and the metric in the form of a number on the right). I'd like to put such a badge on the README of the repository to make this metric visible on a per-build basis.
Azure DevOps does have a REST API that one can use to access built-in aspects of a given build. But as far as I can tell there's no way to expose a custom statistic or value that is generated or provided during a build.
(The equivalent in TeamCity would be outputting ##teamcity[buildStatisticValue key='My Custom Metric' value='123'] via Console.WriteLine() from a simple C# program, that TeamCity can then consume and use/make available.)
Anyone have experience with this?
One option is you could use a combination of adding a build tag using a command:
##vso[build.addbuildtag]"My Custom Metric.123"
Then use the Tags - Get Build Tags API.
GET https://dev.azure.com/{organization}/{project}/_apis/build/builds/{buildId}/tags?api-version=5.0
We are looking at removing developers from production and want a simple kind of deployment management tool. One suggestion that some members are using with SalesForce is Jenkins. I have never used Jenkins or any kind of deployment tool before. I normally just copied my code from IDE and updated the file in the SuiteScript file cabinet.
Does Jenkins work for NetSuite? Or what do you recommend for this purpose?
We are planning to use Bit Bucket (which runs Git in the background) as our version control in case that matters.
Thank you for any help
IMO the greatest challenge in integrating with any CI environment(be it Jenkins or any other) is the fact that you can move code files from one system to another using code/APIs but, NOT things like scripts, custom records, fields its deployments , etc. for which you need a bundling process and hence, manual intervention.
NetSuite in recent Suiteworld 2015 said that its coming up "Change Management" which would allow you to put everything that is part of your app to version control system such as git. Please see SuiteAnswer Id 42387, when this feature is rolled out, you can integrate with your CI tool to automatically copy/deploy your app details to an another NetSuite account and run your tests there and accordingly pass/fail your build.
Why do you want to remove developers from Production? This will severely hamper their ability to create solutions for your NetSuite account and will create a ton of overhead for them.
If you must have them out of Production, then probably your "best" option would be to have them build their solutions in Sandbox and then use SuiteBundles for deployment to Production. A Production Admin would need to update the appropriate Bundle(s) for all Production migrations.
NetSuite has also built a SuiteCloud IDE plugin for Eclipse which allows uploading and downloading files (no copy-paste necessary), so if you're not using that I would recommend it.
We are using Jenkins for our own internal automated testing, but not for deployment into NetSuite. I do not know if someone has already built a NetSuite plugin for Jenkins; it is likely you would have to build your own file upload mechanism using the NetSuite Web Services SOAP API, but that would still only allow deployment of source files. Developers will most likely also need to be creating and updating custom records, fields, lists as well as Script records and Script Deployment records, which you will not be able to do through Jenkins or any other tool that I know of.
I'd like to make use of the "Team Foundation Server Build Extensions Power Tool" to import JUnit test results into TFS within a custom build template designed to run Maven build through TFS.
The importing part works fine, but the overall build status is not set correctly: If any tests fail, it ends in "Succeeded" and not in "Partially succeeded". This seems to be a shortcoming of the Power Tools.
A possible workaround would be to set the build status (the TestStatus in particular) in an explicit activity. I'd like to do that based on a condition activity that checks if any of the imported tests have failed.
However, this seems not to be easy to do, and I'd like to avoid creating a custom activity for this purpose.
Can you give me some hints on how to formulate a condition in a TFS 2012 build template that checks if any of the then already imported tests have failed?
The condition expression I was looking for is:
BuildDetail.BuildServer.TeamProjectCollection.GetService(Of Microsoft.TeamFoundation.TestManagement.Client.ITestManagementService).GetTeamProject(BuildDetail.TeamProject).TestRuns.ByBuild(BuildDetail.Uri).SelectMany(Function(tr) tr.QueryResults()).Where(Function(tcr) tcr.Outcome = Microsoft.TeamFoundation.TestManagement.Client.TestOutcome.Failed).Any()