We configured TeamCity to do nightly builds based on a time trigger at 8pm on a standalone VCS root.
The root is configured to pull the tip. It is also set to do a clean checkout every time.
Has anyone else encountered an issue where not all modified files up to the point in time that the configuration is triggered on will be included. So for example we had a nightly build at 8pm on 8/13/2009, a checkin at 5pm, one at 6pm, but when the build triggered at 8pm on 8/14/2009 some of the changes are included and some are not.
I might be missing something really obvious here, but the result is a "successful" build that does not include all the changes!
Any help greatly appreciated.
I'd recommend you to submit an issue at the bug tracker. Enable debug logging and attach the VCS logs for the problematic checkout to the submitted issue. Refer to the Reporting Issues document for the details.
Otherwise, it's hard to say anything without the version information and the logs. Such issues can be solved much faster via JetBrains tracker/support than here.
Related
We're using TeamCity 9.0.4.
Our full builds take over three hours. While a build is in progress if new commits come in they get queued with, apparently, a VCS snapshot from the time they were queued (I can't see that behaviour specified anywhere, but it's what I've observed).
So by the time the next build is dequeued there may be many builds queued up as developers have been committing changes. The intermediate builds are usually not useful at this point - we just want it to skip straight to the latest build for that configuration.
Other build systems I've used only queue one additional build per configuration and takes its VCS snapshot at the point it is dequeued. This has the effect we want.
I can't work out how to achieve this with TeamCity. What am I missing?
According to our documentation, TeamCity should perform the following build queue optimizations: https://confluence.jetbrains.com/display/TCD9/Build+Queue#BuildQueue-BuildQueueOptimizationbyTeamCity
If it does not work for you, I'd recommend upgrading your server to the most recent version first, and if it does not help, create an issue in our tracker with details about these builds.
I think you've specified this in your trigger.
Edit Configuration Settings | Triggers | VCS Trigger | Show advanced options | Trigger a build on each check-in
That option should be unchecked. The wording is a little confusing I guess. Even with this unchecked, each VCS commit will queue a build but it won't force them to be built in isolation.
We are using TeamCity 9.0.0. The server got corrupted for reasons not relevant to this discussion, so I had to rollback to a stable snapshot (we use Amazon AWS snapshots), which was roughly 12 hours old. I lost some of the builds that happened during those 12 hours but that's ok.
The restore seemed to work, but now the VCS Triggers are not happening. The VCS root is from TFS 2013.
I tried checkin in new changes and builds still don't trigger. I tried running the build manually and it doesn't pick up the latest changes.
It looks like something got out of sync when I restored the snapshot.
Thoughts?
--------Update 1 -------
I looked at the history and I see several builds triggering after I rolled back my server so I think that is not related. I tried creating a new VCS root and removing the existing one. I checked in a change and the build triggered fine. I tried a second check in and this time the build didn't trigger. It's almost like it misses some changesets.
Try cleaning Server cache at <TeamCity Data Directory>/system/caches. If even that doesn't work try deleting and re-creating the VCS.
I've configured sonarqube server on my local machine to run and I committed the initial project with Analysis mode. Also, I created an ant target for the developers to run in incremental mode to view their new issues. I installed issuesReport on sonar server and using it from the ant file to generate html files.
However, when each developer syncs with svn and runs the ant target, they see violations by other developers under the new issues instead of only their issues.
I expected the sonarqube plugin only scan newly edited file by the developer, but is instead showing all the new files that are introduced by other developers.
To make it work properly I have to run an analysis mode from my machine. However this fixes the problem only for me, my colleagues still see all the violations as new.
How does SonarQube decide if an issue is new or not? If each developer has to run a full analysis every time, this would be big over head. Is there something am I missing?
Thanks in advance for your time and help.
An issue is considered "new" if it does not exist on the analysis server. If you run a full analysis on a CI server on a scheduled basis, it will feed the server with issues and reduce the risk of developers seeing other developer's issues in issues report in preview mode.
Please note, that the sonar documentation says, incremental mode is only for the developers and that too for the code they run against sonar prior to scm (SVN or GIT) commit.
See incremental section on the page: http://www.sonarqube.org/analysis-vs-preview-vs-incremental-preview-in-sonarqube/
The sonar report, when run with incremental mode, will show the developer, how much issue will be generated, if he commits the code. This way developer gets to know, what he can do to keep the sonar issues low. This is the whole purpose of incremental mode.
Hope this answers your question!!!
I have two build configurations- a dev configuration (builds on every checkin), and a QA configuration (builds on-demand, whenever a version for qa is released. We don't do continuous deployment (yet)).
When a version for QA is released, I'd like to be able to know what issues have been resolved since the last version. (format is not important- report / chart / text...),
Meaning- i'd like to know all the issues that have been changed to 'resolved' since the date of the last build in this configuration.
I'm using tfs teamcity issue tracker.
Any ideas?
You probably know already that TC has a "Fixed in Build" value?
I find it tricky to use because if we click 'build' once too often, the list of resolved issues gets all messed up.
Thus I'm also interested in expanding the feature, I just posted;
http://devnet.jetbrains.net/thread/438721
API to access "Fixed in Build" value?
Recently I updated the cigame-plugin for Hudson to version 1.12. Now I recognized, that no build get points at the moment. The builds are SCM-triggered and the CI-game is activated for the project and the user. What is going wrong? How can I fix it?
EDIT: I have to correct, the update to the new version of the plugin isn't the problem. Looking through the build-history I can see, that after this update builds got a score. But at some point the builds are not longer scored. Nothing happened to hudson at this time, no restart, no reconfiguration etc. Simply SCM-changes came in and triggered builds.
EDIT 2: The ci-game-plugin counts a score for builds started manually, but not for builds started by changes in version-control. I have no idea why it behaves this way.
EDIT 3: Further investigation shows that I have this bug with the same stacktrace produced.
This is so specific to the current state of the Hudson plugin ecosystem, I suggest you go directly to the users mailing list with the question, where the plugin developers can help you directly.