I am having problem while implementing a pre-push hook. The developers need to run a static code analyzer before they push the code to the git repo. But usually they don't and hence break the build.
Thus, I have written a pre-push hook; which is a shell script to execute the static code analysis ( and copied to .git/hooks) directory but it is not working correctly. This has to be a client-side hook but it is not working as expected. And I dont want to implement this functionality in a pre-commit or post-commit hook since I want static code analysis to be done on the developer's machine before he/she pushes the code (and not when he/she) commits the code.
Thus, please provide your insight as to how I can execute a task (static code analysis) on the client machine before git push command.
As #sestus said, hooks need to be set up client-side, they are not part of the Git repository. It makes sense if you consider that Git is a distributed system and hooks can execute arbitrary code.
What you can do is check in the script into the repository (e.g. to $REPO_ROOT/git-hooks/pre-push) and use the build toolchain of your project to set the up a symlink (ln -s ../../git-hooks/pre-push .git/hooks).
Related
I use the vscode extension to modify code in a github depot but i would like to know if it is possible to execute the code without downloading it
You could add a GitHub Action in your repository, which would checkout your repository, on demand, when you trigger it manually.
That same GitHub Action ca, execute any command you want inside the checked out repository (on Azure server: no need to download the code).
The GitHub Actions for VS Code could be used to trigger that same workflow directly from your VSCode, but might imply a clone first.
I've been looking for a solution how to manage my project with git for quite some time now. I want to have one instance as the main repo for connecting the entire project. Each app should be its own git instance.
During my search I found both git submodule and git subtree. For both tools I found an instruction how to insert an existing reppo. However, I am interested in how to proceed from the beginning. I mean here from the command $ django-admin startproject myproject Where do I enter the git init? When I create a new app
$ django-admin startapp new-app and how do I use this as subtree/submodule?
Until now I have always found instructions that refer to a remote repo. Is this always necessary? I am not sure if I want to publish every Django app on Github. But I want a version control system just for me. Is this possible?
I have to say that so far it has been enough to manage my "projects" locally. Now I want to work together with others and I don't want to install the whole Django Project locally but only provide me with single functions or modules.
It would be a great help if you could explain to me how that works.
TL;DR
How to manage (start and expand) a Django Project with git. The apps should be their own git repos.
The purpose of submodules is to allow you to graft an existing repo/library into your git. Rarely do you want to do this. Instead you want to use PIP tools to install your libraries as part of library management.
This is essentially a git question. If you don't have a remote repository, you can still use git. With that said, the reason you want a remote repository is so that you can collaborate with others, and have a stored version of the code separate from your workstation.
There are services that let you have private repos even without a paid account. Bitbucket is the most well known of these services and is comparable to Github in most ways.
first: We use a github repository in the team for some projects.
I'm using scripts defined in the pre-commit hook directory, locally (works perfect for my commits).
What I need is for every user (collaborator) to use the hooks without using symlinks or asking them to put them on their home folders.
Is there a way to set them up so the users can't commit if the scripts don't exit 0?.
Thanks.
As Henrik alluded to, in the Enterprise version, there is such a thing as the pre-receive hook. It runs server side and so you would not need to install it on each collaborator's local machine. But you are using github.com actual, and they don't allow pre receive hooks , nor do I expect they plan to; allowing indivduals to run scripts on their server isn't likely in their business plan. So that likely won't help you unless you are in a position to go to the enterprise product
There are some remedies you do have, however, but it won't be equivalent. You can , for example, set a protected branch . You could thereby make it only you can check into that branch, and you of course would be using the local hook, every one else would be using a pull request.
Additionally, you could look into LGTM (Looks Good To Me) or similar automated pull request approval system. I don't believe the official server is up but the source code is there and it could be run by someone else. LGTM allows you to set a number of different conditions that would be closer to an equivalent to your pre-op hook.
Setting up such a system might well be more effort than it is worth to you, understandable; but it is do-able.
The main problem with using pre-commit hooks that come with git is that they are local to your repos and don't get pushed to github.com. I believe under the hood, those hooks aren't even transferred up to the repo on github, and that the pre-commit hook directory itself is not available like it is on the local copy of a git repo.
(I would say more on that architecture of the pre-commit hook dir except A. I am not sure if it is covered by NDA and B. I only saw the way it was on the Enterprise product, not github actual, and C. I don't know if the structure is still exactly the same)
This is a follow-on to my question at https://stackoverflow.com/questions/10226287/jenkins-git-and-eclipse
I'm trying to get a post-commit hook running which will invoke a Jenkins build. I can create the hook, place it in my native Git (i.e. not EGit) hooks directory and it works as intended. However, I prefer to have the hook running in my EGit environment as I don't want the complexity of managing two Git environments. I cannot, however, establish where I should place the hook in order for it to be picked up by EGit - any ideas?
=================
Answering my own question - seems EGit cannot do this - see here
If all you want is to have a commit start a jenkins build, then just configure the jenkins job to poll the git repository and start a build whenever a change (=new commit) is found.
This actually stems from on my earlier question where one of the answers made me wonder how people are using the scm/repository in different ways for development.
Pre-tested commits
Before (TeamCity, build manager):
The concept is simple, the build system stands as a roadblock between your commit entering trunk and only after the build system determines that your commit doesn't break things does it allow the commit to be introduced into version control, where other developers will sync and integrate that change into their local working copies
After (using a DVCS like Git, that is a source repository):
My workflow with Hudson for pre-tested commits involves three separate Git repositories:
my local repo (local),
the canonical/central repo (origin)
and my "world-readable" (inside the firewall) repo (public).
For pre-tested commits, I utilize a constantly changing branch called "pu" (potential updates) on the world-readable repo.
Inside of Hudson I created a job that polls the world-readable repo (public) for changes in the "pu" branch and will kick off builds when updates are pushed.
my workflow for taking a change from inception to origin is:
* hack, hack, hack
* commit to local/topic
* git pup public
* Hudson polls public/pu
* Hudson runs potential-updates job
* Tests fail?
o Yes: Rework commit, try again
o No: Continue
* Rebase onto local/master
* Push to origin/master
Using this pre-tested commit workflow I can offload the majority of my testing requirements to the build system's cluster of machines instead of running them locally, meaning I can spend the majority of my time writing code instead of waiting for tests to complete on my own machine in between coding iterations.
(Variation) Private Build (David Gageot, Algodeal)
Same principle than above, but the build is done on the same workstation than the one used to develop, but on a cloned repo:
How not to use a CI server in the long term and not suffer the increasing time lost staring at the builds locally?
With git, it’s a piece of cake.
First, we ‘git clone’ the working directory to another folder. Git does the copy very quickly.
Next times, we don’t need to clone. Just tell git get the deltas. Net result: instant cloning. Impressive.
What about the consistency?
Doing a simple ‘git pull’ from the working directory will realize, using delta’s digests, that the changes where already pushed on the shared repository.
Nothing to do. Impressive again.
Of course, while the build is running in the second directory, we can keep on working on the code. No need to wait.
We now have a private build with no maintenance, no additional installation, not dependant on the IDE, ran with a single command line. No more broken build in the shared repository. We can recycle our CI server.
Yes. You’ve heard well. We’ve just built a serverless CI. Every additional feature of a real CI server is noise to me.
#!/bin/bash
if [ 0 -eq `git remote -v | grep -c push` ]; then
REMOTE_REPO=`git remote -v | sed 's/origin//'`
else
REMOTE_REPO=`git remote -v | grep "(push)" | sed 's/origin//' | sed 's/(push)//'`
fi
if [ ! -z "$1" ]; then
git add .
git commit -a -m "$1"
fi
git pull
if [ ! -d ".privatebuild" ]; then
git clone . .privatebuild
fi
cd .privatebuild
git clean -df
git pull
if [ -e "pom.xml" ]; then
mvn clean install
if [ $? -eq 0 ]; then
echo "Publishing to: $REMOTE_REPO"
git push $REMOTE_REPO master
else
echo "Unable to build"
exit $?
fi
fi
Dmitry Tashkinov, who has an interesting question on DVCS and CI, asks:
I don't understand how "We’ve just built a serverless CI" cohere with Martin Fowler's state:
"Once I have made my own build of a properly synchronized working copy I can then finally commit my changes into the mainline, which then updates the repository. However my commit doesn't finish my work. At this point we build again, but this time on an integration machine based on the mainline code. Only when this build succeeds can we say that my changes are done. There is always a chance that I missed something on my machine and the repository wasn't properly updated."
Do you ignore or bend it?
#Dmitry: I do not ignore nor bend the process described by Martin Fowler in his ContinuousIntegration entry.
But you have to realize that DVCS adds publication as an orthogonal dimension to branching.
The serverless CI described by David is just an implementation of the general CI process detailed by Martin: instead of having a CI server, you push to a local copy where a local CI runs, then you push "valid" code to a central repo.
#VonC, but the idea was to run CI NOT locally particularly not to miss something in transition between machines.
When you use the so called local CI, then it may pass all the tests just because it is local, but break down later on another machine.
So is it integeration? I'm not criticizing here at all, the question is difficult to me and I'm trying to understand.
#Dmitry: "So is it integeration"?
It is one level of integration, which can help get rid of all the basic checks (like format issue, code style, basic static analysis detection, ...)
Since you have that publication mechanism, you can chain that kind of CI to another CI server if you want. That server, in turn, can automatically push (if this is still fast-forward) to the "central" repo.
David Gageot didn't need that extra level, being already at target in term of deployment architecture (PC->PC) and needed only that basic kind of CI level.
That doesn't prevent him to setup more complete system integration server for more complete testing.
My favorite? An unreleased tool which used Bazaar (a DSCM with very well-thought-out explicit rename handling) to track tree-structured data by representing the datastore as a directory structure.
This allowed an XML document to be branched and merged, with all the goodness (conflict detection and resolution, review workflow, and of course change logging and the like) made easy by modern distributed source control. Splitting components of the document and its metadata into their own files prevented the issues of allowing proximity to create false conflicts, and otherwise allowed all the work that the Bazaar team put into versioning filesystem trees to work with tree-structured data of other kinds.
Definitely Polarion Track & Wiki...
The entire bug tracking and wiki database is stored in subversion to be able to keep a complete revision history.
http://www.polarion.com/products/trackwiki/features.php