buildbot try not working with mercurial

[bgunnison]

Several issues, some may be in my misunderstanding how to use it.

.buildbot/options:

try_connect = 'pb'
try_vc = 'hg'
try_master = '....'
try_username = '...'
try_password = '...'
try_builders = ['... Smoke Build']

1. try client calls "hg diff" in working repository. If there are no uncommitted changes, there is no output. Should "try" fail at the client if there are no changes? Or at least inform the user?

1. The build step that try invokes is:

hgUpdateStep = Mercurial(repourl = RepoURL)

RepoURL is the master repository that the working repository was cloned from.

This fails at the buildslave at:

hg.exe update --clean --repository <build_slave_path>\build --rev <workdir_revision_hash>
...
abort: unknown revision '<workdir_revision_hash>'!

It seems we are not applying the patch as the hg command above expects the build slave repository (which was cloned from the master repo) to be update-able to the working directory. Something is missing or not working.

1. So if I have the use-case correct, only uncommitted changes get "tried" in the above scenario. Our workflow is such that we clone from the master repo and commit many times in the working repo. Then a "hg push" is done from the working to the master after smoke test passes. I need "buildbot try" to interrogate the master repo, then "hg diff -r master_rev -r working_tip" to get the difference between the master and working repos. Then try those changes. Is this possible?

Thanks,

Brian

[marcusl]

Correct. The try was written before DVCS:es, so it doesn't check for non-pushed commits, which it should.

We need to decide whether to:

• send the missing changesets + patch, and optionally clean/strip the slave-repo afterwards
• or, just send one large patch between the user's repo and the slave's 'nearest' revision.

Patches welcome. I think this is a good thing to get fixed. :)

[bgunnison]

Replying to marcusl:

Correct. The try was written before DVCS:es, so it doesn't check for non-pushed commits, which it should.

We need to decide whether to:

• send the missing changesets + patch, and optionally clean/strip the slave-repo afterwards
• or, just send one large patch between the user's repo and the slave's 'nearest' revision.

Patches welcome. I think this is a good thing to get fixed. :)

I was thinking of using hg bundle/unbundle

1) Determine Master rep (MR) common ancestor with Working Repo (WR). This produces a CAR (Common Ancestor Revision) 2) do "hg bundle" in WR to package changes since CAR 3) Send CAR and bundle to Build Slave (BS) 4) BS Clones MR to CAR then applies bundle (this is just like a push) and will exactly replicate WR.

I like the bundle approach as a compressed set of diffs is reliable over networks. An error in text diffs can be very bad.

Thoughts?

[marcusl]

Replying to bgunnison:

I was thinking of using hg bundle/unbundle

1. Determine Master rep (MR) common ancestor with Working Repo (WR). This produces a CAR (Common Ancestor Revision)
2. do "hg bundle" in WR to package changes since CAR
3. Send CAR and bundle to Build Slave (BS)
4. BS Clones MR to CAR then applies bundle (this is just like a push) and will exactly replicate WR.

I like the bundle approach as a compressed set of diffs is reliable over networks. An error in text diffs can be very bad.

Thoughts?

Sounds good!

Having a persisting local clone of the MR would make this even more efficient (less network traffic etc), but we don't need to worry about that in this context. (That requires some global support from buildbot, since we probably want to do something similar for all VCS:es)