Yes, the p4 commands can just be in a windows batch command build step. I'm not sure how you're building / testing though.
Keep in mind that the p4 commands I suggested will open files for integrate in the default changelist. On May 9, 2014 10:21 AM, "Mark Wilhelm" <[email protected]> wrote: > Thanks, I'll give it a go. For #4, are you putting these into a "Execute > Windows batch command" build step"? > > On Wednesday, May 7, 2014 2:18:57 PM UTC-5, Stuart Rowe wrote: >> >> Try this approach (there may be typos / gotchas - it's completely >> untested) >> >> 1) Enable Perforce SCM on your integration project in Jenkins >> - set up the client spec 'myclientspec' to use the mapping: >> //project/dev/... //myclientspec/dev/... >> //project/int/... //myclientspec/int/... >> >> 2) Enable 'Use View Mask', but just for polling (I haven't tried this >> feature yet so I'm just guessing it will work for you) >> - set the view mask to be //project/dev/... >> >> 3) Under Build Triggers, check Poll SCM >> - any submitted changes under the //project/int/... branch should now >> trigger your integration project in Jenkins >> - since we're NOT using the view mask for syncing, both branches will >> be synced to head when the build starts (this is good for continuous >> integration) >> - perforce plugin stores the changelist it sync'd to in the >> environment variable 'P4_CHANGELIST' (this is the latest changelist in the >> Dev branch that triggered the build!) >> >> 4) Now we want to integrate from the Dev banch to the integration branch: >> >> p4 integrate -d -i -t //project/dev/...@%P4_CHANGELIST% >> //project/int/... >> p4 resolve -a >> >> // test the build >> >> p4 submit -f revertunchanged -d "Integration Build" >> >> On Wednesday, 7 May 2014 11:09:17 UTC-7, Mark Wilhelm wrote: >>> >>> ok, some more "work"... >>> >>> I put these commands in the "EWbc" window and it works: >>> "C:\Program Files\Perforce\"p4 -u build-user -P xxx change -o >>> "C:\Program Files\Perforce\"p4 -u build-user -P xxx integrate -d -i -t >>> //Project/dev... //Workspace/Project/int... >>> "C:\Program Files\Perforce\"p4 -u build-user -P xxx resolve -a >>> "C:\Program Files\Perforce\"p4 -u build-user -P xxx submit -f >>> revertunchanged -d "Integration Build" >>> >>> BUT, if I run it again, it fails: >>> "No files to submit from the default changelist. >>> >>> D:\workspaces>exit 1" >>> >>> While this makes sense, is there: 1) a way to suppress the submit from >>> returning a non-zero (i.e. an error) or 2) A better way altogether? >>> >>> >>> Thanks... >>> >>> On Wednesday, May 7, 2014 9:01:04 AM UTC-5, Mark Wilhelm wrote: >>>> >>>> Just a basic setup: >>>> depot/project/dev/src >>>> depot/project/int/src >>>> >>>> I have a continuous build running on the "dev" structure every few >>>> minutes. I have a nightly build that runs on the "int" structure. When you >>>> ask "why don't you want to merge?", are you asking from a manual >>>> perspective? >>>> >>>> I would like my "dev" build to run. When the "int" build runs, I would >>>> like it to check if there were any changes on the "dev" branch/directory >>>> and move them over. Then build what's there. >>>> >>>> I have used some of the commands in a "Execute Windows batch command" >>>> build step, but thought that the "Source Code Management" plugin would be >>>> where I would want to do that. >>>> >>>> In the window I used the following commands: >>>> "C:\Program Files\Perforce\"p4 -u build-user -P xxx change -o >>>> "C:\Program Files\Perforce\"p4 -u build-user -P xxx integrate -i -d -t >>>> //project/dev... //JenkinsJob/workspace/int... >>>> "C:\Program Files\Perforce\"p4 -u build-user -P xxx submit -f >>>> revertunchanged -d "Integration Build" >>>> >>>> On the integrate I get: - all revision(s) already integrated. >>>> On the integrate I get: No files to submit from the default changelist. >>>> and the "Execute Windows batch command" fails the build "Build step >>>> 'Execute Windows batch command' marked build as failure. Even though there >>>> was a change list listed by Jenkins. >>>> >>>> I'm all for changing my direction if there is a more standard/better >>>> way of implementing this. >>>> >>>> Thoughts? >>>> >>>> >>>> >>>> On Wednesday, May 7, 2014 2:58:51 AM UTC-5, Stuart Rowe wrote: >>>>> >>>>> Can you describe your branch structure a little more? >>>>> >>>>> How are your integration builds triggered? If you're trying to move >>>>> changes from your development branch to another branch why don't you want >>>>> to merge? >>>>> >>>>> Conceptually I would approach this as: >>>>> >>>>> 1) start an integration of your Dev branch up to some changelist to >>>>> the target branch >>>>> >>>>> (look up "p4 integrate") >>>>> >>>>> >>>>> 2) now you have a pending integration changelist with the changes from >>>>> your Dev branch applied to your target branch. (assuming there were no >>>>> conflicts that couldn't be resolved). >>>>> >>>>> Run whatever builds/tests you have set up to verify the changes >>>>> >>>>> 3) a) if the builds and tests were successful, submit the changelist >>>>> >>>>> (look up "p4 submit") >>>>> >>>>> b) if anything failed, revert the changelist and make the appropriate >>>>> fixes in your Dev branch >>>>> >>>>> -- > You received this message because you are subscribed to a topic in the > Google Groups "Jenkins Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-users/6R4b-QmPZaQ/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
