[Buildbot-devel] Try Change using Perforce Shelves
Will Wilson
lantictac at gmail.com
Wed Apr 7 16:48:35 UTC 2010
Hi All,
First off thanks for buildbot, it's simply awesome! We're using it at
CryTek to do try builds and tests across a variety of platforms right
now and it's saved us on numerous occasions.
So, on to the subject: We wanted to have some form of try change
support using Perforce but ran into the issue of generating diffs via
Perforce. Basically it's got patchy (pun intended) support for diff
generation and almost no support for applying them. Then we realised
we could use the new shelve feature of Perforce to achieve much the
same thing as a diff. In fact it provides a few additional benefits.
So we came up with the following process for trying changes:
1. User shelves the pending change list in their Perforce client -
this basically means the server makes a copy of the changes (including
adds and deletions) and stores them for later retrieval.
2. A TryChange (custom HtmlResource implementation) invoked via
browser taking the change list number as a parameter.
3. The TryChange class extracts the change list details from Perforce
and submits a new Change object to change_svc with the shelved change
ID set as a custom property.
4. A standard AnyBranch scheduler picks up the change and passes it on
to the relevant build slaves.
5. Builds begin, sync to latest, apply the shelved change, compile and
finally revert the shelved change (avoiding the need to resync - as
you would have to with a normal diff).
As you can see we're using a somewhat esoteric feature of Perforce but
it's pretty handy and avoids the slow resyncs required when using diff
based patches.
What we're *really* missing is a way to use the console with our
system - when several users are making builds concurrently the
waterfall just becomes too messy. The problem is the existing console
display is based on revisions, but in this case although we have a
Change object it doesn't have a "proper" revision associated with it.
So I was wondering if it might be reasonable to use the change_id to
uniquely link changes to builds rather than relying upon the revision.
Would this be a practical solution while still keeping the correct
behaviour for everyone else?
Cheers,
Will Wilson. (CryTek)
More information about the devel
mailing list