I have the following configured Azure DevOps pipeline which is building the Windows version of the Xamarin App, was going to try and get that one working first and the build works, but I'm getting an error in the publish, path not found, the 2 paths look fine but I guess this is down to me not building one of these before.
Build step which works fine
Publish artifact step which fails
The error that I get is as follows
Still trying to work out what I have got wrong, so I will keep going at it but if anyone
has any hints would be greatly apprecaited.
This thread as posted by Hongxin Sui was the solution for me, this is the thread.
Publishing build artifacts failed with an error: Not found PathtoPublish: D:\a\1\s\$(buildStagingDirectory)
However, what I did need to do was create a new YAML pipeline and I copied all the working steps in from the previous classic pipeline, I used the "Copy YAML" functionality and then I used the different Task as stated in that thread. Just make sure you change the case of the "Build" and "ArtifactStaging.." variable names as they need to be lower case not upper case.
Some of the steps that i have done are described below:
Setup Jenkins on remote linux server.
Used own mac as a slave to
run Xcode build
I have setup a Web hook on bitbucket that runs a
build on Jenkins server.
Build gets triggered when i push code to
repo.
I have shared scheme in the Xcode project.
But whenever i push failing tests on my repo the build passes..Shouldn't CI server fail the build..I dont know where am i missing..I have posted some screenshots for clear reference
EDIT: with more research i came to know that build fails but you need to see the test results/reports that fails.How can i see the reports? I cant see any xml files under reports section
Even I have faced the same issue where build was successful even though test cases were getting failed. You can use Log Parser plugin to parse the console output and mark your build as either stable or failed based on the output.
The jenkins runs in a step by step fashion.Build succeeds means your build step is correct and there's no issue with that but it does not mean your test cases have also passed.You need to check that with Junit if your test cases pass or not.
In your execute shell phase, you might need to add set -exo pipefail at the top.
I have TeamCity set up to build some Visual Studio solutions and package them into an artifact. This works just fine most of the time.
However, once in a while (maybe 1 in 100 builds), the files built from TeamCity does not run. We use a lot of dependency injection in our code and some times our application refuses to start because it can't find the correct dependencies in the files. There are no missing files in the artifact, though.
We then force TeamCity to build everything once more (by adding a new line to a file and commiting it), and suddenly our application starts again.
It is then obvious to me that there is something TeamCity has not built correctly, though I'm unable to discover what it is, as all the build logs report no errors or warnings of any kind.
What can cause this strange behavior, and what can I do to prevent it from happening in the future (or what can I turn on to get more extensive logging to try to find out what happens when it fails)?
Check the errors when Team City does not run. Does it say why it cannot run? Sometimes have Team City fail a build simply because the version control system had a hiccup. Based on the error in Team City's log it can be obvious that it was only because of that. If you do not do clean builds try doing that and seeing if it makes the intermittent problems go away.
I'd like to create a build that also deploys to a server too, all in the same build. So the last step is the deployment step. However I don't want it to deploy if the there are ignored tests but I also don't want the build to show as broken. I could fail the build if there are ignored tests but that could cause instabilities in the code base, i.e. false positive. I could solve it with 2 builds with one triggered off the other but again I'm not sure how I would look for ignored tests in build 1
I can track what is deployed by displaying version number from assembly info in the app and updating from the build. Also I can check the build log to see if that build step was skipped. In this way I can see what build the server is running.
Am I going completely insane, does this make sense, should I be doing this, is there a better way of achieving this goal? Any help, as ever, greatly appreciated.
My Hudson projects don't seem to properly aggregate downstream test results and I'm wondering if I've missed a configuration step somewhere. I have two projects, Foo and Foo-Tests, both of which are freestyle jobs.
On project Foo I have the following configuration:
Checked "Aggregate downstream test results".
Checked "Automatically aggregate all downstream tests" under the previous option.
Checked "Build other projects" and specified "Foo-Tests" to build.
On project Foo-Tests I have the following configuration:
Checked "Publish JUnit test result report" and specified my JUnit report XML files.
When Foo builds, it builds successfully and correctly triggers a Foo-Tests build. The Foo-Tests build is successful and publishes the JUnit reports correctly. However, when I look for the aggregated test results in Foo, there's a "Latest Test Result (no tests)" link for the build which sends me to a 404.
Here's what I've tried that doesn't solve the problem:
Tell Foo to "Publish JUnit test result report" with no parameters (there are no tests in project Foo, just Foo-Tests). This caused an error since there were no test files for it to process within the project.
Tell Foo-Tests to "Fingerprint all published artifacts" with no parameters (I was wondering if Hudson treated JUnit reports as artifacts behind the scenes). This caused an error since I hadn't explicitly defined any artifacts to publish.
I'm using Hudson 1.266.
Edit:
I should note that I've found two questions on the Hudson Users mailing list that have no answers and would possibly help solve this:
Question 1 (Nabble)
Question 2 (Nabble)
We're using Hudson ver. 1.324 and had similar trouble. Although you mention that you tried enabling fingerprinting and it didn't work for you, it did for us. We followed the instructions found here:
http://shotgunsandpenguins.blogspot.com/2009/07/how-to-aggregate-downstream-test.html
I was able to replicate your problem with Hudson 1.266. This a Hudson error, which was fixed in a later build (prior to 1.287), so either upgrade Hudson or use this two-click workaround: from the Project page, go first to Latest Build and then Aggregated Test Results.
The problem is that the Project page for Foo is only showing the Latest Test Results link, which has a URL like http://localhost:8080/hudson-1.266/job/Foo/lastBuild/testReport/. Since Foo has no tests of its own, this link has no JUnit XML file to reference and returns the error you mentioned. This was fixed somewhere between 1.266 and 1.287 by redirecting from latestBuild/testReport/ back up to latestBuild/ when there are no tests. The alternative for you in 1.266 is to, instead of clicking on Latest Test Results in the Project page, scroll down a bit and click on Latest Build under Permalinks. This will take you to the latestBuild/ URL, and from there you can click on Aggregated Test Result, which has a URL like http://localhost:8080/hudson-1.266/job/Foo/lastBuild/aggregatedTestReport/. On this page, all your test results from downstream projects will be available under the Drill Down section.
Unfortunately, there is still a problem with the Drill Down links, even in 1.287. From Foo, when you drill down to Foo-Tests as outlined above, you will be taken to a malformed URL, which looks like http://localhost:8080/hudson-1.287job/Foo-Tests/. You'll have to manually modify that URL to insert a / between the hudson context and the job path following it so that it looks like http://localhost:8080/hudson-1.287/job/Foo-Tests/. Then you will be able to actually see the downstream test results.
I haven't had a chance to look through the Hudson source to find the error, but there's already an issue open for this. Its issue 1574, and its been open for almost a year.
On a side note, I really love Hudson for CI, but their interface isn't as smooth as it could be. I look forward to their rework of the UI in ExtJS. Maybe thats what they're spending all their time on.
I fixed the missing '/' issue in Hudson 1.288
The key to using the aggregate downstream tests results is to run fingerprinting on both jobs. In this case, that would be 'Foo' and 'Foo-tests'
Hudson matches up the build with the downstream tests by finding files with identical fingerprints. So this means your fingerprints have to match. Kind of like a crime scene.
the two projects, Foo and Foo-Test, have to know they're on the same stream, so it takes fingerprints (and therefore archiving) of a common file.
i had to pick a file that didn't change between the running of Foo and Foo-Test, and still changed between times they are both run. for me that was an unrelated, temporary .jar generated by Foo in the custom/common workspace for my versions of Foo and Foo-Test.
i.e., i had to let both Foo and Foo-Test fingerprint the same file.
after that, at least with hudson 1.330, things work - aggregated links, drilldown, etc.