I pull requested a fixing typos in some .md files in a Microsoft repository https://github.com/microsoft/MixedReality-UXTools-Unreal/pull/28/commits/a371f7627fd562f4f73e5f87c32fc8b179d98e8f all modifications where done using my Visual Studio Community 2019
After my commit I receive a message "Some checks were not successful" the first one is https://github.com/microsoft/MixedReality-UXTools-Unreal/runs/2009069256
Build #20210302.1 failed
1 errors / 0 warnings
ANNOTATIONS
Check failure on line 21 in Build log
azure-pipelines / Docs
Build log #L21
PowerShell exited with code '1'.
If I click to Check failure on line 21 in Build log it send me to the three files that I changed, but no one show any thing linked to Azure-Pipelines
Lines 21 of each code are:
1st File (Docs/BoundsControl.md)
`UxtBoundsControlConfig` data assets are used to configure:
2nd File (Docs/PressableButton.md) 21st line is the following
Add a [`StaticMeshComponent`](https://docs.unrealengine.com/en-US/Engine/Components/StaticMesh/index.html) (or any [`SceneComponent`](https://docs.unrealengine.com/en-US/API/Runtime/Engine/Components/USceneComponent/index.html)) to the actor and set the visuals property of the `UxtPressableButtonComponent` to reference this new mesh. Also ensure that the local positive x-axis of this mesh component points in the direction the button is expected to be pushed. Any component children of this mesh will move along with it as the button is pushed.
3rd File (Docs/ReleaseNotes.md) 21st line is empty
It seems you have triggered a pipeline run from within a GitHub action. Check this documentation: https://github.com/marketplace/actions/azure-pipelines-action. Since the pipeline failed, you need to check the pipeline in Azure DevOps to see the detailed log.
Related
I am using a pipeline build where my BuildConfiguration parameter has three values (debug, stage and release). The three consecutive builds all say Successful when run. The agent release directory folder only has the last one built! ..\a\release\build.2022.09.19.125822. Why does a multi-build only get one resulting build folder? I did copy these completed builds to another folder, but that seems like an extra step. Am I missing something? I have the "Clean" checkbox unmarked. TIA.
Here's what we'd like to do:
A build completes successfully in TFS 2012
Once complete a separate command line process runs tests via vstest.console.exe generating TRX files.
Once all tests have completed those tests/TRXs are published against the target build that just completed using mstest.exe
Once complete we are able to see those published results in Team Explorer - Builds - View Builds for the target build. Under Summary you can see 100 test runs completed for all 100 tests published against it.
At this point we want to open Excel, connect to the TFS Cube and create an Excel report showing a pass/fail pie chart for the target build.
Can someone advise what Cube data to use. We've already tried a few things without success.
Thank you.
We were able to find the target Cube data. Thank you.
Filters - ''
Columns - Outcome, Test Result Executed By
Rows - Build, Test Run ID, Test Run Title, Test Run State
Values - Result Count
As part of our CI, after each release we create a new branch and manually change the version number in our AssemblyInfo and Config files. This is prone to human error and we have decided to automate this process. So far I have a script that creates a new branch from our Main branch which I run before our build; the XAML has been modified with a number of activities that checks out all the AssemblyInfo and config files, updates the version numbers and checks the changes in.
What I want to do is to make this two stage process into a single process. The idea I have at the moment is to add the "TF Branch" script as an invoke process at the beginning of my template before the "initialize Workspace" sequence; this will create the new branch (say branches\1.2.3.4). After the branch has been created I then use a "TFWorkFold" activity placed just under "Create Workspace", in the TFWorkFold activity I add the new mapping - ( ServerPath = $\TeamProject\Branches\1.2.3.4 - LocalPath = SourcesDirectory) but when the process hits the "Get Workspace" activity none of the source files from the new branch are added to the Workspace.
When I run this on other builds the new mapping is successful, only if the branch has been created before the build is initialized.
Is there a step i'm missing? In my Create branch script i have a ping timer of 600secs to allow the branching enough time to complete before the new workspace mapping is added
Figured it out,
After the new branch is created the build process needs to get the latest source files created. In the Build definition I need to tell it to get the Latest Version, this is set in the "Process" section under "Advanced" then "Get Version" I set the value as "T" for "Get Latest". Done :)
I am getting below error message at the time visual studio activate the feature during deployment
Error Message "Error occurred in deployment step 'Activate Features': Expected hex 0x in '{0xdddddddd, etc}'"
Please find the step details which i have used to create solution/project:
1 Create a Empty sharepoint project in visual studio and set the version 3.5 and target frame work 64X.
2 Add new feature and then event receiver and not done any customization.
3 Deeply the solution and getting above error at the time of feature activate.
Note : i have tried to deploy on both sandbox or farm but no difference.
Thanks in Advance!
Make Sure any GUIDs used in your solution except Features has a dash mark '-'
like this {02C414A0-DC73-46F2-A219-0B4A5D1E3AAE}.
I'm using cruisecontrol.net for integration builds along with external source control. The source control (GETMODS) script fails, this is fine and I know why, but the build stays green for some reason when it's expected to fail. CruiseControl shows the exception on the output window below, so why doesn't the build fail?
ThoughtWorks.CruiseControl.Core.CruiseControlException: Source control operation failed:
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.Execute
(ProcessInfo processInfo)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ProcessSourceControl.GetModifications(ProcessInfo info, DateTime from, DateTime to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.ExternalSourceControl.GetMod ifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.Sourcecontrol.QuietPeriod.GetModifications(ISourceControl sourceControl, IIntegrationResult lastBuild, IIntegrationResultthisBuild)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.GetModifications(IIntegrationResult from, IIntegrationResult to)
at ThoughtWorks.CruiseControl.Core.IntegrationRunner.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.Project.Integrate(IntegrationRequest request)
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Integrate()
at ThoughtWorks.CruiseControl.Core.ProjectIntegrator.Run()
I guess the reasoning would be that the source control block is only used:
to check if there are any changes in the source code which require a rebuild, and
to get all the source code needed for the build.
If this action fails it has nothing to do with the source code and the commits to it. It's an infrastructural problem that prevents the build from happening at all therefore technically the build hasn't fails. It hasn't even started.
With a version control block inside cc.net, it search for repository modification.
If cc.net is unable to contact the repository, it can't start the job.
The result is an exception.
If you want to ignore this, this can help (simple retry counter) !
Can we tell CruiseControl.NET to ignore source control timeout errors?
<maxSourceControlRetries>5</maxSourceControlRetries>
<stopProjectOnReachingMaxSourceControlRetries>true</stopProjectOnReachingMaxSourceControlRetries>
<sourceControlErrorHandling>ReportOnRetryAmount</sourceControlErrorHandling>
I believe this is a recent change to ccnet. We are running two versions on separate machines. Version 1.4 breaks the build if it can't get to our svn repository, but version 1.5 will not break the build. I haven't looked into it yet, but there may be a switch to force 1.5 to break on failure to retrieve code.