Build Cleanup condition

Hi

Is it possible to make build cleanup setting by user defined condition?
For some builds cleanup time may be near 30 minutes. It will be usefull to write condition which will be checked on build start.
It may be analyze of pending changes or something like.

--
Best regards,

Alexander Shishenin
QA Lead at Client Team
Moscow Development Studio
Nival Online
http://www.nivalonline.com

11 comments
Comment actions Permalink

Alexander,

Do I understand you right that you want to write some condition that will define whether the sources should be cleaned before starting a build?

This can be implemented via custom plugin to TeamCity.

BTW, why do you need the feature, what are the conditions that you want to analyze?

0
Comment actions Permalink

Do I understand you right that you want to write some condition that will define whether the sources should be cleaned before starting a build?
Yes

This can be implemented via custom plugin to TeamCity.
Ok, can you post link to document where I can read how to do it?

BTW, why do you need the feature
We have many branches of our project. And sometimes we merging them. It's quite regular, average 2 - 3 times in a week.
After such merge builds can fail because of SVN checkout problems, or data conflicts or many other things.
So in this cases clean checkout is the best way to override all such problems. It's quite stupid, but it always works without such errors.
But it wastes a lot of time on clearing big data folders. Build without clean checkout may take 20 minutes, and 2 hours if it turned on.

what are the conditions that you want to analyze?
We can made some flag file that will changes only with such big merge, or we can analyze comments of pending changes.
Another kind of trigger is force clean checkout if last build on this agent failed on svn update.

Main problem here is agent dependence. Becuase we had to rise some flag, that clean checkout is needed after revision XXXX. And agent had to analyze if there any such revisions between his working copy and current update revision.

--
Best regards,

Alexander Shishenin
QA Lead at Client Team
Moscow Development Studio
Nival Online
http://www.nivalonline.com

0
Comment actions Permalink

Alexander,

It's strange you have problems with automatic checkouts. Maybe there is still something to improve in TeamCity about this. If you think this can be TeamCity's fault, please post an issue into the tracker with all the relevant details (VCS settings, custom checkout dirs, checkout mode, exact error messages and the directory structure on disk on the moment of failure).

As to developing a pluign.
We have a section on our documentation concerning plugins development.

The documentation may need some improvement, so feel free to ask API-releated questions in the forum.

e.g. for analyzing changes you can use BuildServerListener.changeAdded and call SBuildType.releaseSources when necessary.

0
Comment actions Permalink

Yegor,

It's strange you have problems with automatic checkouts. Maybe there is still something to improve in TeamCity about this. If you think this can be TeamCity's fault, please post an issue into the tracker with all the relevant details (VCS settings, custom checkout dirs, checkout mode, exact error messages and the directory structure on disk on the moment of failure).
It is two scenarios.

1. Data conflict in local copy and update. Usually it means that previous build run failed and some errors in reverting results appear. This is our problem usually because of errors in revert scripts.

2. Local copy is locked and svn just failed to start checkout.
Sorry but we failed in repeating this. I can just said that, sometimes shit happens.
If we found the way to repeat it, I will post it.



--
Best regards,

Alexander Shishenin
QA Lead at Client Team
Moscow Development Studio
Nival Online
http://www.nivalonline.com

0
Comment actions Permalink

Hello Alexander,

I suppose you may want watch/vote for http://jetbrains.net/tracker/issue/TW-5646 Improve agent svn checkout by ensuring there are no modified files after update

Regards,
KIR

0
Comment actions Permalink

Hello Kirill,

Improve agent svn checkout by ensuring there are no modified files after update
Yes, but IMHO it should be optional.
Sometimes after build fail it's quite usefull to look at build folder and see what was changed there.
And with heavy night builds it's very usefull to keep all changes which was left by build, because of time to reproduce it. Time cost of this results are very high.

--
Best regards,

Alexander Shishenin
QA Lead at Client Team
Moscow Development Studio
Nival Online
http://www.nivalonline.com

0
Comment actions Permalink

Hello Alexander,

I agree that this should be an option. The question is how to specify it.
I think this option should be enabled by default with a possibility to disable it in checkout rules for a particular build configuration.
Thus, we can set this option on per-build configuration basis (and disable it for nightly builds).

What do you think?

Regards,
KIR

0
Comment actions Permalink

Hello Kirill,

I think that it's not a build property. It's an option for build agent with checkout folder.
If it will be build property we can get in trouble.

For example

We have many build agents which run special builds at night.
And we have regular daily builds which can be run on the same agent by VCS trigger.
So in the morning it can triggers early then we lost all the data left on agent.
No we have such a problem with clean checkout, and have no solution for it.

I think the best solution is some kind of exception handling builder which triggers if build fails or was cancelled or anything except success.
This build triggers automatically on same agent right after build which problems encountered.
So user can gather all recuired info in this build and stored it for later analist.


--
Best regards,

Alexander Shishenin
QA Lead at Client Team
Moscow Development Studio
Nival Online
http://www.nivalonline.com

Edited by: Alexander Shishenin on Oct 31, 2008 11:08 AM

0
Comment actions Permalink

Hello Alexander,

That's interesting. So in fact, you're talking about some rule which enforces clean checkout upon some condition (like build failure caused not by test failure but compilation or something like that). I.e. we can have an option to enforce clean checkout for the build it has failed. Would it solve your problem?

Regards,
KIR

0
Comment actions Permalink

Hello Kirill

I think it will be better to use clean checkout not for build, but for this folder on the agent when it was failed.
Because only this folder can be damaged.
For example if previous svn update failed and TeamCity checkout module can't resolve it.

--
Best regards,

Alexander Shishenin
QA Lead at Client Team
Moscow Development Studio
Nival Online
http://www.nivalonline.com

0
Comment actions Permalink

Hello Alexander,

I filed a corresponding issue at http://jetbrains.net/tracker/issue/TW-6082 .
Thanks!

KIR

0

Please sign in to leave a comment.