Using VS 2017 at 15.8.3 with VSTS for source control.
Upon submitting changes it uses a defined build and displays the "Build Request - XXX" page for build notification.
Recently, I've been getting an error on the page at job end that states Build Request - XXX -- Check-in Rejected (see images). Which is not true, the check-in has been performed by the build process and the shelveset is deleted.
Build Response Page
Log From Build
This issue is caused by the Label Sources task not completing successfully in the build. This is caused by using variables within the Get Sources Mappings, e.g., $/Project/$(BuildBranch) This is detailed at https://developercommunity.visualstudio.com/content/problem/60764/label-sources-does-not-work-when-using-variables-i.html.
The above reference indicted that this issue was fixed, and it was as this only recently reappeared in my builds.
Related
We're in the process of migrating to Jenkins pipeline. We use Jenkins to update the build status of our branches/PRs in Bitbucket.
One of our merge checks in Bitbucket is "Check the last commit for at least 1 successful build and no failed builds". This means that we can't merge unless there is 1 successful build of the latest commit on Jenkins, and no failed builds of the latest commit.
Sometimes, Jenkins builds fail for reasons unrelated to the code and the build is fine next time you run it. However, this means that the branch can't be merged as there has been at least one failed build.
To get around this, we were previously able to tick the box in the build status notifier plugin configuration that said "Only show latest build status". As of yet, we're unable to find any equivalent way to configure this in a Jenkinsfile. Does anyone know if it's possible, and if so how?
This question is a duplicate of Multi branch pipeline with bitbucket build status notifier plugin in jenkins, but that question was never really answered.
It seems that your use case it's covered by the Build REST API of Bitbucket, and there is even a step-by-step example of your exact case, being last build failed for external reasons, and a new build succeeds
In order to overwrite the status of an already reported build, you will need to use the same commit sha and the same key
Regarding the Bitbucket Build Status Notifier, it allows you to specify a buildKey as an optional parameter. You should make sure to specify this parameter, and that the parameter is always the same for all builds of the same job.
That way, a new build of the same last-commit will overwrite the last one, as it will be using the same sha and the same key.
See the API section of the plugin documentation for additional parameters.
I have a build set up in VSTS and at the end I want to Publish my Artifacts to VSTS for releasemanagement and I want to Publish my Artifacts to a file share for other purposes. So I have 2 Publish Artifacts tasks.
To VSTS
To FileShare
I get this error
It doesn't matter in which order I put the tasks. When I put file share first then to VSTS will fail and when I put VSTS first the publish to file share fails.
When I do a commit and a build is started automatically it sometimes works. When I manually start a second build I get the error.
Here is the complete build log: Build log
It's telling you the error: Artifact 0.1.0-unstable.18 already exists.
You can't publish two artifacts with the same name. You will have to uniquely identify each artifact.
We are trying to publish a web service from our Dev box onto the UAT box.
There are no errors when building the web-service, but when trying to publish (using UNC path: \\TEST-SERVER\c$\inetpub\wwwroot\PerformanceReviewWebService) we get the below error message and the process fails:
3>C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets(1475,5):
Error : Could not open Source file: The given path's format is not supported.
what can we do to track down this error and resolve it?
On the target box we have checked the security of the folder:
..\c$\inetpub\wwwroot\PerformanceReviewWebService
and we definitely have access to write into that directory.
We have no build errors.
Here are a few things you can try that may help debug or resolve the issue:
Try launching Visual Studio as an Administrator and retry publishing.
Try publishing to a local location. Does this succeed?
If yes there is likely a problem with either accessing the UNC path or a file/security permission issue
If local publishing does not succeed, make sure you haven't mistakenly moved any of you bin, contents or webconfig files to a different location.
Check for files in Visual Studio that are light grey, or have an exclamation mark next to them (They may be missing from the project).
Attempt to possibly reload the project to a prior state where publishing was successful. Continue making updates gradually until your project is up to date.
Create a new empty project and attempt to publish to the same location. If this works you have something corrupted or wrong in you existing project. You can try excluding files or folders from the build to narrow down which ones may be causing the problem.
In my case a referenced web-project shared content with the web-project I want to publish. After removing it from the content of the referenced project it was working again.
When setting up a basic A/B test on a component using page editor, I received error with the following appearing in the log:
Exception: System.InvalidOperationException
Message: Test item is not in workflow
Source: Sitecore.Analytics
at Sitecore.Analytics.Data.Items.TestDefinitionItem.Start()
at Sitecore.Shell.Applications.WebEdit.Commands.Testing.StartTest.Run(ClientPipelineArgs args)
Attempting to start test created a Multivariate Test Definition Item with empty workflow section in the Test Lab
I'm thinking that those Workflow fields should have been appropriately set when using the UI on the page editor to create and start the test.
I guess I'll try reflector to find that error message in the binaries and keep digging.
Sitecore Version: 6.5.0 (rev. 120706)
I realize this is an old question, but I just encountered the same thing in 8.1 update 3. In my case it was because the workflow associated with testing (Analytics Testing Workflow, unless you've made your own) had been deleted on my local installation. Restoring it from one of our other servers made the error go away.
In Sitecore 8.1 and above there is a setting which can be turned on to allow the content authors to start test via experience editor.
Please add the below settings either as patch config file or
You can edit the value in the config file (Sitecore.ContentTesting.config).
Setting name is “ContentTesting.AlwaysShowTestCandidateNotification”
I have done a number of changes to a build configuration in TeamCity 8. I know I can see an audit trail of the changes that I have done to the build configuration and I can check the details of each individual change, but I wonder if I can select one of those previous versions of the build configuration and restore it; there doesn't seem to be any obvious option in TeamCity for this.
For the avoidance of doubt, I'm not after reverting changes in the source code, but in the build configuration of TeamCity. I changed a few parameters, build steps, triggers, etc., and I want to revert those changes.
You are right ,there is no obvious option in Teamcity to rollback to a previous version.
However, all teamcity build configurations are maintained in a xml file on the local disk drive in the Local Build Server. The files are created in a rolling format (the latest config is called config.xml, the one previous to it is config-1..xml). If you can figure out from the audit page on which exact xml you want to rollback to, you can copy the backed up config.xml to the recent one, or you can make the changes manually.
I would recommend playing with this on a test target first and then doing it on the original target.
As of TeamCity 2017, there is a link to a page with recent changes to a configuration:
Press 'view history' and you will end up on a page where there's a list of changes.
Press 'view change':
There you will see a "diff" comparison, identical to the one you have in git:
Sometimes it's hard to navigate, but you can surely see what was changed. This is especially useful for accidents when you deleted a piece of script, and saved the configuration. This can get your script back.
Hope it helps you after you after 8 years and 4 months!