I have currently 3 codelines in my perforce depot
Main
Development
Release
The idea being changes will be integrated into Main from release and dev branches. But as of now some of the devs are making changes directly to Main branch. Is there a way to freeze check-ins for the "Main" codeline and allow integrations via branch mappings in perforce?
OR if there is any other best practice (restrictions) out there that can be applied to avoid direct check-ins into the Main branch.
Thx
As Adam said, you should use permissions to limit access to the Main branch. You can do this either by using the Admin tool, or by running p4 protect from the command line (as long as you have super user access).
You should limit the permissions for Main to read for most people, and allow write for those you trust to submit to the Main branch. You can also choose to give "normal" users open access instead of read, which will allow them to check files out, but not submit them.
Another thing to consider apart from just setting the permissions is the approach we are running for some of our branches:
We use a review tool (Reviewboard in our case) and have a Perforce trigger in place, which checks if there is a review in ReviewBoard that matches the following criteria:
there is a review associated with the current Perforce change number
the latest review has the "ship it" flag set to True
the reviewer in ReviewBoard is NOT the submitter of the change list.
the list of files in the review matches the list of files in the change list
You could be even more restrictive, e.g. that the reviewer has be to a special person (guard of the branch). The advantage to just setting hard permissions is that you get control over what to submit and in what quality. This would also enable you to submit important bugfixes to the main-branch without prior messing with p4 protect.
Related
I don't have admin privileges. Need to test other's change lists and submit them.
Tried changing the owner of the CL but didn't work without admin.
p4 change -U <creator> <CL>
Error in change specification.
Change <CL> can only be updated by user <creator>
Unshelving the original CL, then testing it, will create a duplicate CL. Duplicate CL is submittable but not the original CL.
Are there any ways to submit a perforce change list of another user without admin privileges?
Based on documentation I'd say no (see below). The way you are doing it is probably the best way using shelving. Another option would be to have an unstable branch that code is okay to be broken and another user can 'release' after testing to a stable branch.
From my understanding, changelists are owned by the user and not really "transferable" like you want.
From Helix 2020.2 documentation on the p4 change command
The owner of an empty pending changelist (that is, a pending changelist without any files in it) can transfer ownership of the changelist to another existing user either by editing this field, or by using the -U user option.
If you start down the "sharing a workspace" path. Don't. "It is actively discourages by Perforce Technical Support" and "it is almost never a good idea to share a Perforce client workspace among multiple users" https://community.perforce.com/s/article/3675
While creating workspace in perforce, I got below error
You should define workspace view in more detail. (minimum 2 depth)
This is not a standard Perforce error, and is therefore most likely coming from a custom trigger set up by your Perforce admin. In order to resolve a custom trigger failure you will need to consult with your Perforce administrator (i.e. the person who defined the trigger) to determine what conditions are required to satisfy the trigger.
If you would like to learn more about how to define triggers, see https://www.perforce.com/manuals/p4sag/Content/P4SAG/chapter.scripting.html
(this is not useful to you as an end user encountering a trigger failure, but may provide additional context on how triggers work from your admin's perspective).
The workaround/fix i got is,
make sure to select a folder in "Workspace root" , which has last two level of empty folders,
for example,
Suppose you choose "C:\Users\stackuser\workspace\project\codes", then make sure, "project and codes are two empty folders
In our Perforce workspaces at work, there are a couple of control files that contain branch information that should never be integrated across branches.
Is there a way to tell Perforce to always ignore these files in integrations?
You could set up a branch spec and use that for your integrations.
You may be able to use some type of permissions through p4 protect, so that only the admin can modify them. I know this works for actually checking out and checking in a file, but I'm not sure about integrating it to another branch.
You could write a server-side trigger script that looks for the control file names and filters them out of an integrate.
There's pretty good documentation on triggers. There's a load of examples too in the public Perforce depot.
I am trying to understand what perforce “jobs” provide over an external bug tracking system and just putting the bug ID in the check-in comment.
I was hoping that "job" could help with How do I see if a branch contains a bug fix in Perforce?
Nothing. Take it from someone who endured years of aggravation working with the Perforce/FogBugz integration mechanisms (the latest being the Perforce Defect Tracking Gateway which uses Perforce jobs as part of the integration). They provide very little return on a significant investment in time setting them up and then trying to figure what went wrong when they stop working (which is often).
I now do just what you suggest. I simply put the FogBugz case number in the Perforce check-in comment, then add that Perforce changelist number to the FogBugz case upon resolving it. As simple and reliable as it gets.
We put the issue ID in the comment but also have a Perforce trigger that updates the issue database (JIRA) with the changelist number. During the next build the automated build process also updates the issue with the actual build number.
A very nice part of this implantation is that the trigger gives an error if the issue is not marked as in progress or the developer doing the check-in is not working on the issue. Therefore it is uncommon for a miss-typed issues ID number to get past the checks.
As a bugtracker, Perforce jobs are somewhat basic. They can be created and modified with the P4V GUI client or using p4 job and p4 jobs on the command line.
The idea is for them to serve as a link (a connector as Perforce calls it or an interface as a developer might look at it) to a third party issue management system and basically provide the information which changelists were committed for which issue. The issue management system can then tap into this information using the Perforce Defect Tracking Gateway (PDF documentation here) and generate bugfix charts or statistics for management or whatever.
We are using this with Jira in both directions with some success. The basics worked pretty much straight out of the box, more advanced use cases (such as e.g. which bugs were fixes in which release ?) or integration with other bugtrackers may require modification of the Perforce job model.
One of the advantages over tracking changelist and issue numbers using commit comments is that you can select the job/issue from a dropdown box when you commit a changelist using P4V.
In practice, developers tend to forget to add the job information when they commit a changelist. This can be enforced using Perforce triggers.
I have a team that will be using CruiseControl for continuous integration, and CC will be running on a Linux server. More than one team member may need to access the CC configuration itself: changing how tests are run, changing notification rules, etc.
What is the best practice for this?
My first thought was to set up a cc-users group, then make a shared directory somewhere (such as /usr/local, I suppose, or a new directory like /projects), where the directory has r/w for the group.
Am I missing any complications with this plan? Obviously, I've never been in charge of such a project before, otherwise I wouldn't ask such a question.
FWIW, my intention is to have all the cc configuration files under mercurial so we can roll back in case of breakage.
I have version-controlled the whole of cruisecontrol configuration, along with the project specific config files underneath it.This way, the write-access can be controlled per requirement, using your source control tool's access control method (in our case subversion) thus providing tracking as well. Whomsoever needs to make a change can checkout the file config.xml in their own workspace and make their changes and then commit. You may want to consider the same approach.