We are using perforce as a source control for Visual studio solution.
Working with P4 and P4V.
Is it possible to add client side pre-commit hook? for instance to ensure the word "debugger;" is not exist in *.js files.
Could find something in Google.
Thanks.
Perforce triggers can be used to enforce such a policy, but they run in the server, not client-side. So most sites that I'm aware of would enforce a rule such as the one you describe using a change-content trigger in the server.
http://www.perforce.com/perforce/doc.current/manuals/cmdref/triggers.html
It's not obvious from your question why you need to have a client-side hook. Is there some reason you don't want to use a change-content trigger?
Perhaps you might consider re-framing your workflow as a code review process, and implement policies like this in your code review tool of choice.
One approach that you could use is a "Custom Tool":
https://www.perforce.com/perforce/doc.current/manuals/p4v/custom_tools.html
Basically you would write a script that takes the changelist as an arg checks your condition on every file in your changelist and calls p4 commit if it succeeds.
Use latest git-p4. My patch for the hook p4-pre-submit is merged into Git's next branch.
The hook is a simple executable script which will stop the submit process to start up if the script exist with non-zero status. So p4-pre-submit hook is pretty safe without any side effect.
See https://github.com/git/git/blob/next/Documentation/git-p4.txt for details.
Please note git-p4 is an independent python script. It's not dependent on any specific version of git. So you can upgrade git-p4 only.
The hook p4-pre-submit has no other interaction with git/git-p4 except exiting status. So you can write the hook in any language (I recommend python).
Here is sample .git/hooks/p4-pre-submit:
#!/bin/sh
cd $GIT_DIR && make test
Related
I need to install small programs I do not fully trust.
Therefore I would like to monitor all files for changes - whether this script places some files it is not supposed to or edits others.
As I want to monitor all folders and files I thought about using something similar to rsync - but is there an alternative to only watch for changes?
Does this way guarantee that I catch everything the software changes? Or are there some kind of "registry-entries" / changes in the configuration, I could miss?
Thanks a lot!
I would suggest you use some kind of sandbox (probably the most straightforward way nowadays is to use Docker).
You could use Git to track all the changes that are made into the sandbox/container:
Initialize a git repo in the root dir
Add all files and commit as the base version
Execute the install script you do not trust
Using git status is going to show you all the changes that were made during installation.
For my nodejs application, I am trying to run a hook through gitolite which performs the following actions (on the server side):
Update the repo to take into account the new changes (git fetch + git reset --hard newref)
Update the application dependencies (bower update, npm update / install)
Check some basic rules (coding rules, unit tests 100% ok, etc). Basically, it runs something like grunt test (jshint, mocha, ...)
Compile everything (grunt build)
Run the application
If one of these steps somehow fails, the whole process is stopped, the old application is restored and the push is denied.
My first approach was to add a pre-receive hook to this specific repo, but since it is triggered before the gitolite update hook (which checks about your rights), this was bad anyway.
So I now think about using VREFs which kind of work like a secondary update hook. So I'm pretty sure it would work like this, however it seems VREFs are usually here to perform only some basic checks, and don't intend to be used as something such a full deployment process.
I've done some research and it seems that usually people use a post-receive hook to deploy their app. This means that if something fails, the push is accepted anyway. I really would like to avoid accepting a commit which breaks the application at some point.
Is there a better way to achieve this deployment?
This question made me crazy!Please help me.
I use the buildbot, VC tool is perforce 2010.
Waterfall: ok
but console view cannot work right.
just print "No revisions available"
If you are using the Periodic scheduler, then buildbot isn't made aware of the revisions in your repository, it just checks every time, and builds the most recent version. Since it doesn't know anything about revisions, it can't display anything sensible for the console view.
To get the console view, you need to tell buildbot about your revisions, either using buildbot.changes.p4poller.P4Source, buildbot send-change or contrib/post-build-request.py. And then trigger your builds using a regular scheduler, rather than a periodic one.
It's probably something environmental in the configuration, such as the Perforce username or the Perforce client spec. The tool is probably issuing a 'changes' or 'sync' command, and since it's not using the workspace definition that you expect, it isn't finding any code in that workspace.
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've been doing some research into finally automating our Development builds and still have one nagging question that I'm hoping the StackOverflow community can solve for me.
My understanding is that an IntervalTrigger when setup properly will check VSS every X seconds for changes and if it finds a modified file, will run my tasks. One of my tasks would be to checkout the AssemblyInfo files and update the version numbers. After these files are updated they would be checked back into VSS.
Thinking about this solution it doesn't make much sense because in my mind, I'm forcing the check for changed files to true every time the trigger fires. Am I missing something here? Is there a way of doing this without triggering an automatic build on the AssemblyInfo check-in?
You can use a Filtered Source Control Block to exclude certain files from the trigger.
I just posted a bunch about my default build process here which may be of some interest to you: SVN Website Development and Deployment Solution
The way I usually configure my projects with CC.NET is to have two project blocks per solution. One configured as an interval trigger that does nothing more than get the latest from my repository, build the solution, and run unit tests. The other is a schedule trigger that does all the things the other one does, but actually publishes a build. This includes changing version numbers, publishing files, etc. This might work in your case, since the change in version would cause the interval project to trigger, but only once.
Checking the automatically generated AssemblyInfo into the version control system is a bad idea, don't do it. You'll get a lot of noise (50% of all commits!) in your history. Also, it does not give you any new information - you can always pull this from VCS. Have your build script autogenerate those files is a good practice, but don't push those changes back!