Whenever I clone a repository, I see on the GithHub page a certain icon indicating the build - for example build passing.
I am extremely new to professional code development. I would really appreciate it if someone could tell me what a particular build status indicates ? Brief answers would do !
Software projects consist in a set of source files, and of an automated procedure used to "build" the executable product or library. This procedure is called "the build". It can fail for various reasons:
compilation error
automated tests failing
coding conventions not respected
bug in the build script
etc.
"Build passing" indicates that the build procedure completed successfully. "Build failed" indicates that the build procedure failed.
Usually, this build procedure is executed automatically each time a new commit is made on the repository. A continuous integration server like Travis or Jenkins downloads the project for the last commit, then launches the build, checks that it succeeds, and updates the build status.
Related
TLDR: How can I arrange it so that a snapshot dependency does not trigger new builds?
For my test processes to run, they need to run on a "Test" environment. Creating such an environment is simple, but lengthy; it can take as much as 45 minutes to an hour to finish building a test environment. Further, the name of the environment, and other such variables, is not fixed until the environment has finished building.
In my TeamCity build definition, I could put "build environment if missing" as a build step. However, that means that the first test of the day will take 45 minutes to run.
Instead, we created a separate build, that is scheduled to run every morning, that builds the test environment for the day. Our test build then has a snapshot dependency to that build in order to use the parameters of that build to determine the environment information, and everything works as expected, except for one issue:
When a new test is run, it frequently seems to trigger a rebuild of the test environment creation.
We don't want this to ever happen; the test environment creation is 'done' for the day and should not need to run again until tomorrow. How can we achieve this?
You already have time based trigger => environment will be prepared every morning
Create Snapshot Dependency in your product TC configuration (not in that one which is preparing test environment) and tick 'Do not run new build if there is a suitable one'
Your configuration used to setup test environment should not have any VCS root (or point to some calm place of source control where submits will not happen). To physical setup your environment you should not need any source code mapping etc. - you may consume everything needed through your own NuGet packages for example.
Note: In this workflow every build of your real project will enlist build of configuration which sets test environment (so it's physically in build queue) but
when it's turn come up it will compare changes since last build => no submits on VCS found (it's pointing to calm place in SourceControl due step 3)) and so build will be skipped in <1s
How can I detect build failed status in post action script from Xcode edit scheme section for different targets?
I am planning to send sms to me if build is failed in CI.
Thanks in advance.
Post build scripts (specified in the Xcode project file) are only executed if the build passes, but not when it fails.
If you want to handle this case you should use a Continuous Integration solution (ex: https://fastlane.tools/) or service (https://bitrise.io/ - CTO here), or simply write a script which calls Xcode's Command Line Tool xcodebuild which returns an error code if it can't perform the given action (build, archive, test, ...), so you can handle this case the way you want to in the script.
I've recently moved to TFS213, did an install on a new machine.
After building one of my projects the result showed an error on MsTest. It turned out that it had invalid switches (as in Error when running unit tests from MSBuild)
Invalid switch "/publish".
Invalid switch "/publishbuild".
Invalid switch "/teamproject".
Invalid switch "/platform".
Invalid switch "/flavor".
I have found various posts online about this and have done the following :
I have installed vs2013 professional on the build-machine, in various posts it's says to install ultimate but I don't have a license for ultimate.
The problem still persists, the MsTest.exe is started from the correct location (it's only installed in C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE, and the build-process does find the MsTest executable.
for now I've disabled testing in my build-definition but that's not the 'ideal' situation ;-).
Should I just remove the invalid 'switches' or is there some other solution
TIA,
Jurjen.
I had the same issue and solved it by modifying the properties of the "Run MSTest for Test Assemblies" step in the build.
Summary of fix: I changed the Flavor, Platform and Publish properties of the "Run MSTest for Test Assemblies" step to "" (empty string).
Details of fix: I did this in a custom template but I think you could also make the change in the default template.
Disabled tests (as you did) to make sure my build would work as a baseline.
Followed instructions here to create and use to a custom template:
http://msdn.microsoft.com/en-us/library/dd647551.aspx
Tested that the Custom Template worked by adding a "Write Build Message" step to the build (per advice in article above).
Searched for (drilled down) to the "Run MSTest for Test Assemblies" step in the build. This took a long time because it is deep. I am sure there is a faster way to find it but I am not sure how.
Set Flavor, Platform and Publish properties to "" (empty string). (See photo).
Committed template changes to TFS.
Re-ran the build and it worked.
When all tests pass I don't see test results on the build results screen.
When a test fails it causes the build to fail. I don't see the test failure in the build summary but it does show up when I click "View Log".
This isn't ideal, but at least I have the tests running and preventing a build from passing when a test fails.
So, I am having a bear of a time figuring this one out. I have looked around, and cannot seem to find any information on this.
What I want to do is have my unit tests ALWAYS run EVERY time I build my code in XCode. I have read a number of posts, including this question here. I have followed the instructions to the letter, and the build will not run the tests.
What I have done:
My Test suite is a target dependency of my main build
My main build has "Test After Build" set to Yes
All of the tests under the "test" phase in the Scheme are there, and checked
If I run the tests manually - through cmd+U or the menu - the tests run. I have added a failing test to try and force the build to fail - so I can be sure they are running. The build continues to pass fine, and the tests are never run.
I am positive I have missed a step in here, but for the life of me I cannot find any documentation related to it. Anyone have any other advice or steps I should be doing?
It doesn't matter whether or not "Test After Build" is set to yes or no in your Something.app target. It is only necessary to set "Test After Build" to YES in the unit test target. Also make sure that both "Test" and "Run" are selected for your unit test target in the scheme editor under the "Build" tab options. To see the results click on the Log Navigator View > Navigators > Show Log Navigator (command 7).
In your main target's Build Phases, add a new Run Script build phase. The content of the script should be:
"${SYSTEM_DEVELOPER_DIR}/Tools/RunUnitTests"
That will run the tests - but only if it can find the .octest files generated by your project. RunUnitTests wants PRODUCT_NAME to be the name of your unit test, and WRAPPER_EXTENSION to be .octest (these are Xcode variables). If your main target is an aggregate target that has your tests AND your app as dependancies, you can probably make it work with that in mind.
I am doing builds using a custom MSBuild Script in TFS2010 SP1. The Build Type is a gated Check-In and fails even though the MSBuild log shows as successful on my builds. What would trigger a failure after MSBuild is complete and before The build definition finishes the gated checkin
It turns out that the DataCollectors were failing as the test runs were happening. This was diagnosed in the event log under VSTT. Unfortunately it doesn't update the normal MSBuild logs and no other information is given into the Workflow logs.
I ended up disabling the datacollections in the local.testsettings file that is being used as part of the build process.