[dumb] [p4] RE: Automated build trigger

jab jab at pobox.com
Thu Jun 24 22:52:12 PDT 2004


On Jun 24, 2004, at 5:45 PM, Fawad Khan wrote:

> Currently, I use the "p4 changes" command on the set of directories 
> listed in the build script to figure out what changes have taken place 
> since the last build and if there are change I trigger a build. For 
> example the following would be used to determine changes to the l3mob 
> branch since the last build assuming the last build labeled the files 
> within the l3mob branch with label AP_1.2.0.17-l3mob:
>
> p4 changes 
> //depot/foo/bar/feature_branches/l3mob/... at AP_1.2.0.17-l3mob, at now
>
> The problem with triggering the automated build using the above 
> command is that the presence of the filespec using the label limits 
> Perforce to look for change lists which affect only the files which 
> have been labeled with the given label. But, if a new file was 
> introduced into the feature branch after the last build, then the new 
> file will not be considered when the above p4 changes command is 
> subsequently issued. Because of this problem, we were trying to come 
> up with an alternate mechanism to trigger the automated build. But, so 
> far, I have not come up with a viable solution.
>
> Any ideas on how to solve this problem?

The first thing to say is "look at 'p4 review' because it's the real 
tool for post-submit anything."

I gave a talk at the 2000 Perforce User's Conference on the topic of 
post-submit scripts,
mainly to emphasize that all post-submit scripts are really the same 
form:

	Put something like this in a script, then run every N minutes from 
'at' or 'cron':

		NewChangelists=`p4 review  -t  checkcompile_cntr | cut -d' ' -c2`
		for n in $NewChangelists
		do
			echo Processing changelist $n
			# put in code to actually *do* something, here*
			p4 review -t checkcompile_cntr   $n
		done

(Now, that's written in Bourne shell from memory, but you get the idea.)

The second thing to say is, "you will probably want to run a 'p4 files 
//depot/pathname/you/like/...@$n,@$n`
as the first line of your code to *do* something, because if there's 
files in intersection of
//depot/pathname/you/like/... and the set of files modified in the 
changelist it's examining, you
have no work to do (for that changelist.)

Note that the above is pretty close to the answer to your question: how 
to figure out
if things have been updated in tree by a specific changelist or set of 
changelists.
(Summarized answer: use 'p4 files, but give it real changelist numbers 
and not just labels'
and also '... but use p4 review as the framework, because the structure 
will deal with
post-submit needs - which is really the thing you're aiming for, 
anyhow.')

The third thing to say is that my model, above, is OVERLY simplistic 
for the test-compile
case. (You'd really want to have two counters: 
last-attempted-changelist-counter and
last-succeeded-changelist-counter.)

	-Jeff Bowles




More information about the perforce-user mailing list