5 messages in com.perforce.perforce-user[dumb] [p4] RE: Automated build trigger| From | Sent On | Attachments |
|---|---|---|
| Fawad Khan | 24 Jun 2004 17:45 | |
| Erik Purins | 24 Jun 2004 19:04 | |
| jab | 24 Jun 2004 22:51 | |
| jab | 25 Jun 2004 02:58 | |
| Rich Geiger | 25 Jun 2004 13:01 |
| Subject: | [dumb] [p4] RE: Automated build trigger![]() |
|---|---|
| From: | jab (ja...@pobox.com) |
| Date: | 06/24/2004 10:51:50 PM |
| List: | com.perforce.perforce-user |
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




