I use fake to build multiple Visual Studio Projects via: MSBuildRelease buildDir "Build" appReferences.
If all projects compile without errors everything works fine, but when one project returns an error, the sequence stops.
How can I continue compiling all Projects, even if some may give an error.
FAKE has support for Build Failure Targets and Final Targets. These are One shot calls in the event of failure for the first and at the end of other Targets for the latter. It doesn't show dependency association.
http://fsharp.github.io/FAKE/specifictargets.html
You can however get all your targets with getAllTargetNames and run each target you want alone with runSingleTarget. The GetErrors gives back a mutable list, so you check if the last error is severe enough and then log it and either stop or push a new empty list into errors. Seeing the code:
let mutable private errors = []
so something like
GetErrors() <- []
might allow you to skip over Targets in error. You can also put the errors in another parent list and reassign at the very end. That way you can post activate the Build Failure Targets runBuildFailureTargets and Final Targets runFinalTargets to do their expected processing.
https://github.com/fsharp/FAKE/blob/master/src/app/FakeLib/TargetHelper.fs
Related
I have a pipeline that I could debug and worked until today - last time when I debugged it and I could see the debug results was this week.
When I click the "Debug" button it stays disabled, as if it would be running, and then it's enabled again, after 2-3 seconds, without any debug occurring.
Only relevant information I found is here, but the solution does not apply to me - I changed the branch to master, the branch that is allowed to publish, I did a successful publish from it, and the debug is still not working:
I found that error often happens when the publish phase of the Debug fails.
Try a Publish to see the real error where the Validation fails
Debug Button Disabled after pressing, no output
Debug Button Enabled, no output
LE: I tried to trigger the published pipeline and it failed with the same message, so I guess the link in the original post mentioning Publishing to get the actual error is true, just that in my case I needed to trigger the pipeline as well, not just Publish (publishing did not return an error).
I started to recreate the pipeline from scratch and debug after I was adding each component.
In the end I started to replicate this behaviour when I added the Stored Procedure component in the Foreach.
So I tested the Dataset connectivity for that SP component - I use parameters for its connection data and the test failed - The expression '{item().ClientDbServer}' is not valid: the string character '{' at position '0' is not expected."
So the expression #{items().ClientDBServer} that worked for a parameter in a pipeline does not work in this Stored Procedure. I removed the "{" and "}" and now it debugs.
An error message would have been nice at Debug, but no such thing. Validation passed.
I keep getting problems with Grails domain classes and using run action on Application
It appears as though the domain traits and transformations don't seem to pick up or process gorm traits correctly and compiler fails (had problems with columns without sufficient type data or bootstrap failing when I load a value into a property and it says the property doesn't exist etc.
Essentially I can't trust using the run on Application in the IDE and I don't know whether my domain classes are working or not.
However if I go to gradle view and 'bootRun' the same code it will compile and run successfully!
I've had this before and I don't know if its a grails failure or Intellij issue with Grails projects.
When I right click Application and run the command terminal shows it running like this
"D:\Program Files\Java\jdk1.8.0_181\bin\java.exe" "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2018.3\lib\idea_rt.jar=7620:C:\Program Files\JetBrains\IntelliJ IDEA 2018.3\bin" -Dfile.encoding=UTF-8 -classpath C:\Users\willw\AppData\Local\Temp\classpath1951982944.jar lcm.network.app.Application
In my latest iteration this throws a compile error on the bootstrap (as opposed to an error on domain class) with this
groovy.lang.MissingPropertyException: No such property: maintainer for class: com.softwood.domain.MaintenanceAgreement
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:66)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.setGroovyObjectProperty(ScriptBytecodeAdapter.java:547)
at lcm.network.app.BootStrap$_closure1.doCall(BootStrap.groovy:37)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:98)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325)
at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:264)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1099)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1034)
at groovy.lang.Closure.call(Closure.java:418)
at groovy.lang.Closure.call(Closure.java:412)
at grails.util.Environment.evaluateEnvironmentSpecificBlock(Environment.java:541)
at g
However that domain class absolutely does have that property - see below
class MaintenanceAgreement extends Agreement {
String level
Map category = [:] //p1 to p5 and sla details
//static belongsTo = [serviceProvider : OrgRoleInstance, maintainer: OrgRoleInstance]
// implemented as unidirectional many to one ! mag point to org
static belongsTo = [maintainer: OrgRoleInstance]
static constraints = {
level nullable:false
//serviceProvider nullable:true
maintainer nullable:false //ref to maintainer party
category nullable:false
}
}
So you spend hours trying to sort spurious problems in your code using right click /run on Application.
I'm forced to have to use grails bootRun - which in this case runs the app just fine.
You lose some details when working this way as the stack trace for compile errors is not so clear.
Has anyone else had this problem with gorm traits processing domain objects in Intellij? Moreover how can I 'fix' the Application run action to fire all the right behaviours as bootRun seems to do?
Mike W's answer seems to be the easiest fix. When you're in IntelliJ and edit your domain models it seems to get confused and app won't compile/run as expecting.
So if bootRun works, but running application from the IDE does not, then doing this tweak seems to get things back to steady state.
If you make edits to your domain models, right click on the domain folder. Then click rebuild 'default' about half way down the menu. Wait till complete, then run your Application instance again by right click RunApplication <main> in the menu and the app should start successfully (or with debug) from within IDE.
This is easiest answer and gives best feedback to the developer with minimal extra rebuild action to remember.
Having a CI pipeline that is using Teamcity and Octopus deploy and build scripts written with Cake I want to be able to display the error messages that generated by the build script.
Now the message displayed is:
Exit code 1 (new)
In order to be able to see the real error message one must view the build log and parse it.
So, even when using build script, I want to be able to display the build results in overview page and the list of errors like in the following picture:
I know that Cake provides support for integration with TeamCity, but the documentation and examples are not that straightforward.
Ca anyone provide some helpful information regarding this subject?
Cake implements a method to be able to write a build problem
TeamCityProvider​.BuildProblem(string, ​string)
Looking at the source code for this provider, I can determine that this will build up a string to output that conforms to the build script interaction specified in the TeamCity documentation, specifically reporting the build problem
##teamcity[buildProblem description='<description>' identity='<identity>']
by calling BuildProblem("Some message", "Some identity") this will output
##teamcity[buildProblem description='Some Message' identity='Some identity']
TeamCity should then fail the build and display the message as per the documentation;
To fail a build directly from the build script, a build problem has be reported. Build problems appear on the Build Results page and also affect the build status text.
You need to edit the cake build scripts to properly trap the exception and call the above method, so it will write to the output stream correctly.
I can replicate this behaviour using a PowerShell script to write the buildProblem message to the ouput stream
This will then show the very message in the build results on the overview page
Hope this helps
I am busy with configuring our new TFS 2015 server (on premises) and trying to get the new vnext builds to work properly.
What I now have are some extra powershell scripts that increase the version number of my assemblies.
It also changes the buildnumber in TFS by calling the API method (see tfs rest api). My json body only sends the new build number (eg. {"buildNumber": "1.0.1.1234"}) and this works fine.
Now I have added some major, minor and patch version variables in the build definition for the version. Once the build is done this should be updated and so I thought to do the same kind of thing and just send an update API call to the corresponding builddefinition endpoint. The documentation says the revision number is mandatory so I have added that. For the rest I only added the changed variables.
The api call works, but the nasty thing is that it will update the whole definition and clear out all the other settings which I did not provide in the json body. I also tried first getting the defintion through the API, changing the json values for the variables and send that back but that didnt work correct also.
So does anybody know a good solution for this?
As a workaround what I did for now is adding a dummy build definition (eg. "_ProjectVersion") totally empty except for the variables and my build task now uses that build definition to get the latest version numbers and update them. So the api call still empties that whole build definition but since it only contains my variables I dont mind.
I am also doing this in powershell since all scripting should be automated and done in powershell.
The problem I have is that the API call to get the json of an existing BuildDefinition returns invalid json when managed in powershell.
For example the "#{multipliers=[]; will fail with 'must have at least one value' even though a 'json validator' may report as Valid. The correct json is {"multipliers": "[]",
I am using TeamCity 7.1. I want to get a list including the last build of each build configuration (build type) that is currently not running. I found this question: TeamCity - How do you get a list of the last finished build of each project through rest api? but the REST URI in the answer did not work for me.
<teamcity-server>/httpAuth/app/rest/builds?locator=sinceBuild:(status:failure)
seems to work and gives me all builds that succeeded after failing before.
But the opposite
<teamcity-server>/httpAuth/app/rest/builds?locator=sinceBuild:(status:success)
does not return any builds.
I know that I can get all build types, iterate though them and get the most recent finished build using
<teamcity-server>/httpAuth/app/rest/buildTypes/id:<build-type-id>/builds/running:false?count=1&start=0
("count=1&start=0" may not be necessary)
but I am not really sure that what I get is really the latest build. Also this requires many REST calls for all build types. A neat solution would use only one REST call.
Any ideas?
As per the TeamCity REST API documentation from JetBrains, the builds can be located either of the following ways:
<teamcity-server>/httpAuth/app/rest/buildTypes/id:<build-type-id>/builds/running:false,status:success
OR
<teamcity-server>/httpAuth/app/rest/builds/running:false,status:success
This is must to have the buildType is being suffixed by a <buildTypeLocator> as per the current REST API if you are trying to query something under the buildType and <buildTypeLocator> can be id:<btXXX_internal_buildConfiguration_id> or name:<Build_Configuration_name> (Quote from documentation). So it is must that you need to specify build id or build name.
But, the ideal way as you expected will be something like:
<teamcity-server>/httpAuth/app/rest/buildTypes/builds/running:false,status:success
Probably, you can raise this up in TeamCity Support I suppose.