[#BAM-1017] Never Can Retrieve Changelogs

Bamboo

Never Can Retrieve Changelogs

Created: 12/Mar/07 11:27 PM Updated: 29/Mar/07 02:20 PM

Component/s:

Repository (CVS)

Affects Version/s:

1.0.1

Fix Version/s:

1.0.3

Time Tracking:

Original Estimate:

1 day

Remaining Estimate:

1 day

Time Spent:

Not Specified

Issue Links:

Reference

This issue is related to:

~~BAM-900~~ Bamboo expects the CVS module name to be a directory in the build dir after doing a checkout, and loops inifinitely doing checkouts

Participants:	Brydie McCoy [Atlassian], Mark Chaimungkalanont [Atlassian] and Sam Berlin
Since last comment:	1 year, 28 weeks, 1 day ago
Company:	limewire.com (Find related issues)
Number of comments:	10
Internal Priority:	1. Highest
Labels:

Description

« Hide

All plans are unable to retrieve changelogs for the files that changed.

The bamboo.log shows:
—
2007-03-13 00:05:50,943 INFO [BAM::BuildChangeDetector] [CVSRepository] Found 6 changes from update
2007-03-13 00:05:50,986 INFO [BAM::BuildChangeDetector] [CVSRepository] Running CVS log command: "log -N -r -d>2007-03-12 17:55:32 build-macros.xml AtomicLazyReference.java DefaultThreadFactory.java DefaultMessageID.java AbstractSecurityToken.java FakeProxyServer.java "
2007-03-13 00:05:50,987 INFO [BAM::BuildChangeDetector] [CVSRepository] ... in: "/spare/bamboo/data/xml-data/build-dir/LW-COMPILE/limewire"
2007-03-13 00:05:53,154 INFO [BAM::BuildChangeDetector] [CVSRepository] Found 0 changes sets in the change logs
2007-03-13 00:05:53,154 INFO [BAM::BuildChangeDetector] [CVSRepository] something wrong with the change logs, so lets work out what's changed...
—

A little bit of detective work (by running the command and similar commands on the commandline) shows the following problems:

1) None of the files include their directories, which leads to the server knowing nothing about the files.
2) The date & time are not quoted, which leads to the server printing out a change on the given date, not at the given time. It also causes the server to look for a change in a file whose name is the time.
3) The '>' is not escaped, which on the commandline caused the result to be piped to a file whose name was the date. (I don't know if this effects the process the CVS command is run in.)
4) The '-r' parameter is used, which leads to only a single revision being shown. This effectively hides any earlier commit messages on files that were updated twice between builds.

This is a huge problem. Any help would be greatly appreciated.

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Sam Berlin added a comment - 12/Mar/07 11:37 PM

Note that the command should probably also use -dTIME1<TIME2 format instead of just -d>TIME1, since a file could have been changed on the server while a build was happening. Using -d>TIME1 would include the most recent change, even if it happened after the build was triggered & updated. TIME1 should be the time the last build was triggered, and TIME2 should be the time the current build was triggered.

[ Permlink | « Hide ]

Mark Chaimungkalanont [Atlassian] added a comment - 13/Mar/07 03:29 PM

Sam,

Definitely sounds like a major problem. We still have CVS projects internallty and it still seems to work, so I don't think it's a fundamental problem with the CVS integration.

Is the CVS server running on a different timezone to the Bamboo server?
Is there a large network latency between the Bamboo and CVS servers

We have seen problems when the time settings is a little off (especially around day light saving) and the other "Unknown" instances can happen if the network socket drops out.

Let me know if any of these lines ring true...

Cheers,

Mark C

[ Permlink | « Hide ]

Sam Berlin added a comment - 13/Mar/07 03:39 PM

The CVS server & Bamboo are running on the same machine. The CVSROOT I'm using is just "/cvs" (/cvs being a symlink to the repository). Updating & checking out works, and logging works in the sense it hits the server... but returns with 0 logs because the server can't find any matching files.

[ Permlink | « Hide ]

Mark Chaimungkalanont [Atlassian] added a comment - 14/Mar/07 02:00 AM

Sam,

Are you running a standalone or the WAR?

I might try to give you a custom WAR with some extra debugging to try to get some more info

Cheers

Mark C

[ Permlink | « Hide ]

Sam Berlin added a comment - 14/Mar/07 10:10 AM

We're actually running the standalone with Apache setup to use ProxyPass[Reverse], and the web-context of the startup script altered to use /bamboo. If I can expand the war into the standalone directories, that'd work fine.

[ Permlink | « Hide ]

Mark Chaimungkalanont [Atlassian] added a comment - 14/Mar/07 04:01 PM

Sam,

I've attached a new 1.0.3-SNAPSHOT WAR at https://support.atlassian.com/browse/BSP-43. Can you try using that version and attaching your atlassian-bamboo.log to this issue after you check in some files?

This build should also resolve ~~BAM-1026~~

Cheers,

Mark C

[ Permlink | « Hide ]

Mark Chaimungkalanont [Atlassian] added a comment - 16/Mar/07 06:50 PM

Sam,

Thanks for you detailed support request. That's been very handy in trying to figure out what's going on.

We should be able to get back to you about updates on this in a day or two.

Cheers,

Mark C

[ Permlink | « Hide ]

Brydie McCoy [Atlassian] added a comment - 25/Mar/07 09:29 PM

Hi Sam,

Sorry about the delay this took a little bit longer than expected.

From your discussion with Mark in your support request (BSP-43), I am assuming that the problems you are having are because you were using ampersand modules. Bamboo currently has some issues with detecting changes in ampersand and alias modules.

In 1.0.3 (soon to be released) Bamboo will pick up changes for ampersand modules as long as it is defined with a root module with the same name as the ampersand module.

myampermod myampermod &othermodule1 &othermodule2

By the looks of things this is how yours is already set up.

If you are still having problems after upgrading let me know.

Cheers
Brydie

[ Permlink | « Hide ]

Sam Berlin added a comment - 26/Mar/07 12:47 AM

Hi Brydie,

I'll be sure to checkout Bamboo 1.0.3. That should fix the problem for three of our plans. The fourth plan, LW-COMPONENTS, still will have some problems because it's defined as "comp-test &components &lib" (see BAM-1015 for more information about that).

[ Permlink | « Hide ]

Sam Berlin added a comment - 29/Mar/07 02:20 PM

I'm pleased to report that Bamboo 1.0.3 has indeed fixed this problem, for all of our plans (including LW-COMPONENTS). So it looks like the ampersand module doesn't need a root module defined with the same name (though I can't report what happens if it has a root module with a different name; not having a root module does work though).