I have one requirement of one build definition should invoke the other build definition.
Based on the result of the first one, the second one should get triggered.
Is there any option?
Following the article "
How to keep your streams flowing smoothly in Rational Team Concert 3.0.1", you could set up the post-build deliver step in order to deliver to another stream, monitor by another build.
If the first build goes well, it delivers to the second stream, which is monitored by a build workspace associated to a second build, which will start then.
Note that only a RTC 4.0.6+ (February 2014) allows to fine-tuned the conditions for which a post-build deliver will be triggered.
Related
Is there any version/source update step or action that needs to be done when building GCFs with Cloudbuild. Or is there anyway to make sure that pubsub topic invokes the latest GCF version?
I've got a bunch of GCFs that are built with CloudBuild, and afterwards invoked by a pubsub topic. Weirdly some of them (not all) throw an error from a previous version of the GCF (the last GCF build actually fixes the error).
GCFs source code shows what's expected: the latest version of the code
Yet, GCF throws error that was in the GCF's previous version source code.
That line doesn't even exist in the source code of the currently active GCF's version (GCF > Functions > FUNC_NAME > Source).
In some occasions it's been a few hours since a GCF deployment and the first invocation.
From the best of my understanding, a new code is to be used at a "cold start" of a next "slot/instance" of a cloud function... And if you have some instances being used constantly - when one invocation is finished, the next one uses this (just became available) available "runtime environment slot", so that the environment is not created from scratch. Thus, it may take some time until all those "slots" are substituted with new, which have the new version of code being uploaded when the environment is created.
You might prefer to delete the cloud function, and then recreate it (using the new code), or drain the pubsub, so there is a pause in cloud functions being triggered.
I'm having a hard time understanding how to properly install and uninstall custom actions, and what the purpose of rollback is. I have a custom action called CreateFSRegistryLink that creates a REG_LINK registry entry (which cannot be created by MSI/InstallShield directly AFAIK). I think I have this running properly for the most part because if the link is already there, it just returns ERROR_FUNCTION_NOT_CALLED, which MSI seems to handle gracefully, proceeding with the rest of the install. This ensures that multiple instances of the product can be installed cleanly (we have a multi-instance product).
The problem comes during un-install. CreateFSRegistryLink appears to be running again in non-rollback mode. From the MSI log I can see that it's running as it should during an install and but it also runs during an uninstall:
I'm checking the mode with:
if (!MsiGetMode(hInstall, MSIRUNMODE_ROLLBACK))
When the condition is true I log a message, "CreateFSRegistryLink is running in non-rollback mode." When it is false, I log a message, "CreateFSRegistryLink is running in rollback mode, so was skipped." I have never seen the second message show up in the log.
I have CreateFSRegistryLink set up with In-Script execution of "Deferred Execution in System Context." I also have another custom action DeleteFSRegistryLink set up with In-Script execution of "Rollback Execution in System Context". I see it getting skipped during an install, but not during an un-install (I suspect it's running normally during an un-install, but have not added logging to confirm this).
I also have a custom action CountOtherFSSystems that sets FS_SystemCount to the number of systems (instances) besides the current instance. I set DeleteFSRegisryLink to have a condition to only run when FS_SystemCount<1 in the Exec sequence. This is how I can tell that it is being skipped during an install because MSI reports that the condition wasn't met and so DeleteFSRegistryLink was skipped. I expect this to help ensure that it only runs when the last instance is being un-installed. I think this condition is working based on log output, but I don't know how to get this DeleteFSRegistryLink custom action to run properly during un-install without the CreateFSRegistryLink action re-installing the link. The last reference to DeleteFSRegistryLink I see in the log is:
MSI (s) (08:CC) [09:42:23:708]: Executing op: CustomActionSchedule(Action=DeleteFSRegistryLink,ActionType=3329,Source=BinaryData,Target=DeleteFSRegistryLink,)
I haven't added logging to this function yet, so I don't know if it ran, but when the un-install is done, the link in the registry is still there. This is not entirely surprising because immediately after that I see that CreateFSRegistryLink ran again:
MSI (s) (08:CC) [09:42:23:708]: Executing op: ActionStart(Name=CreateFSRegistryLink,,)
Action 9:42:23: CreateFSRegistryLink.
MSI (s) (08:CC) [09:42:23:708]: Executing op: CustomActionSchedule(Action=CreateFSRegistryLink,ActionType=3073,Source=BinaryData,Target=CreateFSRegistryLink,)
MSI (s) (08:0C) [09:42:23:739]: Invoking remote custom action. DLL: C:\windows\Installer\MSI37E1.tmp, Entrypoint: CreateFSRegistryLink
MSI (s) (08:70) [09:42:23:739]: Generating random cookie.
MSI (s) (08:70) [09:42:23:739]: Created Custom Action Server with PID 7640 (0x1DD8).
MSI (s) (08:18) [09:42:23:786]: Running as a service.
MSI (s) (08:18) [09:42:23:786]: Hello, I'm your 32bit Elevated custom action server.
CreateFSRegistryLink is running in non-rollback mode.
I followed the rule at https://msdn.microsoft.com/en-us/library/aa371369(v=vs.85).aspx of "A rollback custom action must always precede the deferred custom action it rolls back in the action sequence" which is still really not making sense to me seeing this log output and results. I think I'm missing a few key points here.
This is on my 'required reading' list for MSI and a good place to start:
Installation Phases and In-Script Execution Options for Custom Actions in Windows Installer
The idea is that every change made by MSI should be transactional. You should be able to rollback the state change on failure during an install, upgrade, repair or uninstall.
Occasionally you'll come across an API where this is not possible. An example would be deleting a user account or interacting with the old IIS metabase API. If the API doesn't support a .commit() .rollback() ability then you have to just make the change in the commit phase execution. Considering that commit phase can be disabled by disabling rollback you have to do it early in those scenarios.
Read the white paper a few times, digest it a bit and then follow up with any other questions that you still have.
Edit: This is how I ended up setting up my custom actions:
CountOtherFSSystems runs with Immediate Execution after InstallInitialize under all circumstances to set FS_SystemCount to the number of other instances that are installed.
RollbackFSRegistryLink runs with Rollback Execution in System Context after CountOtherFSSystems under the condition FS_SystemCount<1 And $FSRegistry = 3 (When the FSRegistry component was being installed local). It calls the function to delete the registry link.
CreateFSRegistryLink runs with Deferred Execution in System Context after RollbackFSRegistryLink under the condition $FSRegistry=3. It calls the function to create the registry link.
A bunch of other functions in the sequence execute, and then we get to the standard action WriteRegistryValues.
RollbackDeleteFSRegistryLink runs with Rollback Execution in System Context after WriteRegistryValues under the condition $FSRegistry<>3 (when the FSRegistry component was being removed, but the rollback needs to put it back). It calls the function to create the registry link.
DeleteFSRegistryLink runs with Deferred Execution in System Context after RollbackDeleteFSRegistryLink under the condition FS_SystemCount<1 AND $FSRegistry <> 3. It calls the function to delete the registry link.
TestError runs with Deferred Execution in System Context after DeleteFSRegistryLink. It calls a test function that just returns an error condition if the user says it's OK (via MSIProcessMessage) to introduce an error for test purposes here. (This function will be disabled for the production builds.)
I tested the following cases:
Error during installation of first instance - no registry entries or links are created.
Error during installation of second instance - only the first instance's registry entries remain, and the link remains also.
Error during uninstall of second instance - both instances and the link remain in the registry.
Error during un-install of last remaining instance - While the error is still displayed (before rollback occurs) I can see that the registry entries and link are all gone, and after proceeding, I see the rollback has restored the registry entries and the link.
Successful un-install of second instance - link and first instance's registry entries remain.
Successful un-install of last remaining instance - link and all registry entries are removed.
Please comment if you see anything I missed here. It seems pretty comprehensive to me.
To throw in my 2 cents: The issue seems to be related to custom action conditions. Regarding your call to MsiGetMode to see if it's a rollback, why bother? You sequence a rollback custom action before your actual deferred CA, and by definition it will be called only if the original custom action was called, and it's defined as a rollback CA and it needs no conditions. It may be that your uninstall CA can be the same as the rollback CA, but strictly speaking an uninstall CA can assume that its counterpart install CA worked correctly if it is coded correctly and failure causes the install to fail, whereas a rollback CA may need to assume that the install CA may have only partially worked and needs to check more system state.
If CreateRegistryFSLink is being called on uninstall then your condfition on that CA is incorrect.
If your code did or did not do something then it's up to you to remember what it did and the rollback CA undoes it.
The rest of it appears to be about the conditions on your custom actions. If you want one to be called only on uninstall of the product, then use REMOVE="ALL". If you have CAs related specifically to feature or component uninstall then (as Chris says) use a component or feature condition, they are here:
https://msdn.microsoft.com/en-us/library/aa368012(v=vs.85).aspx
If you want an uninstall CA to run as long as the product is not being upgraded, then REMOVE="ALL" and NOT UPGRADINGPRODUCTCODE will work.
So if you're still stuck, it may help to post your definitions of the CAs, in particular the conditions and types.
Within our company we use TeamCity for both automatically triggered build configurations, that are triggered quite regularly, and also manual not-as-often build configurations.
Examples of automatic builds are: up-to-date light builds, tests, etc. These are usually triggered because new code/data is available.
Currently, there is big chained process for a release of our product on all platforms. This is done manually by running the last composing build config, and it will do all the build configurations it needs to. None of them are ever automatically triggered, and all are unique to the release build chain.
My questions are, as the amount of agents we have available is quite limited, is it possible that the release process has priority in a way that it would:
Pop any automatic builds and add them again to the queue (just cancelling would be fine, but less desirable) as long as the release chain is ongoing?
Delay any automatic trigger build until the release build chain is finished?
I would understand that there is no existing solution for this, as the only thing I'm using for now is the priority classes. And even though it does work nicely for deciding what stuff on the queue to execute first, it doesn't affect any ongoing build process.
Do you know a great solution for that, or have an idea on how I could tackle this myself by implementing something using, for example, the REST API?
TeamCity have custom build queue priorities feature. You can configure your release process build configurations to have higher priority, so they will run before any non-prioritized build, and there no need to remove/readd builds from/into queue.
we have some depending builds, and i want to start them all after all... (talking of RTC/Jazz build definition, which are used in RTC/Jazz source control - we use the build-engine from RTC/Jazz)
build framework
build server [depends on 1.]
build (start) unit test server [depends on 2.]
build client [depends on 1.]
build (start) unit test client [depends on 4.]
build (generate) allover report [depends on 1.-5.]
build (publish) if all was ok... [depends on 6. if ok]
is there a way to add a sequence into different build definitions? the builds are performed on two different build engines which are even on different build server. right now i have to copy the results and publish all manually...
one important note: these are the nightly builds, where all work of the day is brought together... they are triggered via the 'schedule option' in each build definition. but think what happens when one build is not yet ready and the other already starts? (this already has happened and i want to avoid it furthermore)...
what is the proper way to handle this? (maybe i was using the search option wrong but no results in google and Stackoverflow)
The build scheduler management in RTC isn't as complete as a TeamCity or Jenkins (actually, RTC4+ allows to delegate that job scheduling feature to Jenkins)
But if you want to introduce a sequence between builds definitions, you can look at post-build delivery, introduced in "How to keep your streams flowing smoothly in Rational Team Concert 3.0.1".
The idea is, if a build succeeds, to trigger a deliver to another stream (post-build deliver step).
If that other stream is monitored by another job, that job would only starts if the previous one succeeds: sequence achieved.
This seems simpler than adding pre/post-build extensions points.
Note that post-build steps currently don't get run when a build is invoked by the Team Concert Plugin for Jenkins. See WI 277270.
You can place a post request to jour jazz server after each successful build like:
localhost:/jazz/service/com.ibm.team.build.internal.common.ITeamBuildRequestService
<request>
<method>requestBuild2</method>
<interface>com.ibm.team.build.internal.common.ITeamBuildRequestService</interface>
<parameters xsi:type="com.ibm.team.repository.common.services:ComplexDataArg">
<type>COMPLEX</type>
<value xsi:type="build:BuildRequestParams">
<allowDuplicateRequests>true</allowDuplicateRequests>
<personalBuild>false</personalBuild>
<buildDefinition itemId="YOUR_BUILD_DEFINITION_NAME" />
</value>
</parameters>
</request>
My setup up is such that TeamCity kicks off a build on successfuil building of another project.
This works well, but now I need to constrain it such that the above only happens in a certain window during the day.
i.e. Kick off a build of Y on successful build of project X, but only between the hours of 9 and 5.
From what I can tell, I can't AND or OR two Build Triggers in order to achieve this. Does anyone know of a way around this?
Many thanks
Another solution could be to add the first-step in build Y which will return success-code in specified interval; and next step will be executed only in this case;
To address Justin's comment: my understanding is that you want project Y builds skipped outside of the specified time window.
I can offer the following solution:
Create an auxiliary build Z:
Build Steps. One build step: command line runner, the script checks current time and returns error level = 0 if the time is between 9 and 5, and a different error level otherwise.
Build Failure Conditions. Have it fail if build process exit code is not zero.
Build Triggering. Triggered by a successful build X.
Modify build Y to be triggered by a successful build Z rather than X.
This will do the trick.
However, you'll have to spend a build configuration for Z, which may be an issue if you're using the Professional Edition of TeamCity, with its limit of 20 build configurations. You could also do without creating build Z, by adding the same build step into Y, but I don't know if it's going to meet your needs. The downside is that it will cause project Y to have a number of builds failed only because it was not the right time for them. Still, you'll save CPU resources by avoiding the remaining steps of build Y (if resource saving is what you're trying to achieve).