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.
Related
I have a simple Ktor application using application.conf files. The documentation mentions that I can specify a custom configuration file to use as such :
Now, I would like to do exactly the same, except that I start my application using ./gradlew run.
Using ./gradlew run -config=... won't even run, while using ./gradlew run -Dconfig=... seems to gloriously ignore the input I give it.
What is the proper way to provide a custom configuration time when starting my Ktor server with gradle?
Supplement.
If you use idea to run a program, you can add the -config parameter to Program arguments.
e.g.
Ok, answering my own question after further research. The answer in this case is to run gradle as such :
$./gradlew run --args="-config=src/main/resources/application.test.conf
As per [the gradle documentation](https://docs.gradle.org/current/userguide/application_plugin.html#:~:text=Since%20Gradle%204.9%2C%20the%20command,setArgsString(java.).
We have started using Appveyor for CI with our Github repo and all has went fine. We have our build script working (appveyor.yml) in the repo, and it successfully builds and produces an artifact. Now on to my question
We are trying to pair our builds now with codecov.io which says it will scan it during the CI build. And it does support appveyor, it merely says to add this to the yml
after_test:
- bash <(curl -s https://codecov.io/bash)
Which we did, but nothing happens. Does this mean i need an actual test script to run, before it will send off the code to codecov? It is a C# project, and we have it compile, and generate the .exe which we then package into a zip which can be downloaded.
What are the point of these "test scripts" when we already know it compiles and produces an exe? I am a bit confused on how to use this properly..
I believe here https://github.com/codecov/example-csharp is good example of running codecov tests on C# project with working Appveyor configuration. Please look at readme.md file in that repo for greater detail.
From the Documentation
You need to add the OpenCover nuget package to your Visual Studio solution which is used to generate code coverage analysis:
PM> Install-Package OpenCover
Secondly, you need to either write a PowerShell script (if you intend to generate code coverage and upload the result interactively) or you need to add a few entries in you CI config file (if you intend to let your CI generate the coverage).
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.
If I understand correctly I can make a build step conditional using this plugin: https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin
First does this plugin work the Post-Build steps?
Second is there a way to make Post-Build steps conditional without a plugin?
The scenario I have is I am supporting both WebDriver and Selenium IDE tests with one universal Jenkins Job setup. If they have checked in either type of test it runs them. I then want it to conditionally look if any results files show up and if so then do the publish results Post-Build step, otherwise skip that step.
Currently if no results show up it simply marks the build as a failure since no test results were found.
Any suggestions would help!
You can make any Build step execute as Post-build step.
Install Flexible Publish plugin
Install Any Build Step plugin
Under Configure System, look for "Flexible publish", and choose Any build step from drop-down.
The configure Job.
In your Job configuration, add Post-build action called "Flexible Publish".
Select condition.
Select action.
It is posssible but it is a bit messy and can not be done with ui only.
Create the the conditional build step in the build block and save the konfiguration. Edit the xml file and move the whole conditional build step it to the post build block. Reload the jenkins configuration and it works like intended.
I have been playing around with TeamCity to get a CI environment up and running.
I started by following Troy Hunt's 'You're deploying wrong', which was very useful, however I wanted to split the packaging and deployment into 2 seperate steps, for the following reasons:
I wanted to pass some additional flags to msdeploy, which isnt possible (to m,y knowledge) by using the MSBuild Package and Deploy that Troy describes.
I can easily disable the Second Build Step i.e. deployment, if I ever need to build the package but not deploy it.
I wanted to use the -skip flag on msdeploy to prevent it from deleting certain folders, which again I couldn't find any method of doing without passing as an argument to the command line.
So, in my first MSBuild step I just have the parameters:
/P:Configuration=%env.Configuration%
/P:VisualStudioVersion=11.0
/P:IgnoreDeployManagedRuntimeVersion=True
And then I have a second Build Step that uses a command line build runner to execute the following msdeploy command:
"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package="C:\ProgramData\JetBrains\TeamCity\system\artifacts\MyProject\%system.teamcity.buildConfName%\%teamcity.build.id%\MyProject.Web.csproj.zip" -dest:auto,ComputerName='https://devserver:8172/msdeploy.axd?site=MyWebsite',UserName='domain\username',Password='password',IncludeAcls='False',AuthType='Basic' -skip:objectName=dirPath,absolutePath=media$ -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -retryAttempts=2 -allowuntrusted
The problem with this is that apparently TeamCity doesnt publish the artifacts until all the build steps are complete, so therefore the Command Line process fails because the package zip file doesnt actually exist at that point.
I have read something about publishing artifacts whilst the Build is still in progress but that does seem like a bit of a hack.
Any advice would be greatly appreciated.
You would be better have two builds vs two build steps.
The first (Build A) would have 1 build step that would do the building then the second (Build B) would just do the deployment in one build step using the artifacts from the first.
So under the first configuration tab of build A, you would specify the artifacts that would need to be made available from the first build. You can then run the build and confirm that under the artifacts section everything you need is available. (These will show when build A has completed running).
Then under the dependencies section (Can't remember the exact name, and I'm away from my TC instance) of Build B you can set it up to use the artifacts of build A which would then be used for the deployment.
Once you have all that working, you could add a build trigger to have Build B run after a successfull execution of Build A, then if you at one point just wanted to run Build A, disable the trigger on build B or pause the Build B configuration which will stop the trigger from firing.