While using pre-commit sometimes I just want to know that filenames are going to be passed to the hook, just to verify that by --from-ref and to-ref are correct. For example, I was running:
pre-commit run flake8 --from-ref $(git merge-base master HEAD) --to-ref HEAD
and I wasn't sure of what files where passed to my flake8 hook, adding --verbose does not help because flake8 will not output the filenames either.
So it's there any way to tell pre-commit to only output the list of filenames without running the actual hook?
pre-commit provides a special identity hook for this purpose
you can configure it by doing:
- repo: meta
hooks:
- id: identity
alternatively, if you're just trying to figure out --from-ref / --to-ref -- you can use git diff A...B --name-only as that's what pre-commit is using behind the scenes
disclaimer: I'm the author of pre-commit
As a workaround you can define a new hook in your .pre-commit-config.yaml that runs ls
- id: ls
name: show files
language: system
entry: "ls"
pass_filename: true
Then you can run:
git add .pre-commit-config.yaml
git commit # so that the new config takes effect
pre-commit run ls --verbose --from-ref $(git merge-base master HEAD) --to-ref HEAD
and you will get a list of the files "selected" by pre-commit.
Related
I search the method to copy files to "test" host when I launch the "git push" command.
git push ------- TO REPO --> REPO_SERVER
\
\_________ TO DIR --> Host_TEST
Git Version: 2.20.1
It sounds like you are trying to (re) invent CI/CD.
If you are using GitHub or GitLab as a remote server you can use Pipelines (or Actions in GitHub).
In there you can define (almost) anything you want to happen after a push, I am assuming your Host_TEST is accessible online.
In case you are running your own git server
You can implement "push to deploy" using the post-receive hook. Hooks are scripts that are placed inside .git/hooks and executed at a precise phase of a git command. you can find several example implementations in .git/hook. See here for more information: Setting up Push-to-Deploy with git
In case you don't have access to your own git server
You can use the pre-push script on your local machine, BUT THIS IS A BAD IDEA
This hooks is executed after you execute git push but before git actually pushes anything. If your script fails (i.e non-zero return code) it will not push.
Also, if your script manages to copy but then git fails to push you will end up testing code that's not in your repo.
If all this sound way too complicated
You can create a bash function that does both operations and add it to your .bashrc.
Here is an example:
push_copy() {
if git push
then
# Copy for command here: scp ...
else
echo "Failed..."
fi
}
I tried to deploy the Hexo on my GithubPage.
The generate process looks fine, but error happens when I deploy it on my GithubPage.
Here's the deployment part in _config.yml:
# Deployment
## Docs: https://hexo.io/docs/deployment.html
deploy:
type: git
repo: https://github.com/ZhangYuef/ZhangYuef.github.io.git
# branch: Hexo
Generate
Deployment
So what's going on there?
Thx for help! :)
The context you provided in the question is not sufficient...
But according to invalid chars on the screenshot, I suppose that your Chinese file path may be the cause.
References:
Node JS Error: ENOENT
Why does ENOENT mean "No such file or directory"?
try to update the _config.yml like this:
deploy:
type: git
repository: https://github.com/fakeYanss/fakeYanss.github.io.git
branch: master
yaml is very very very strict, and indent is important!
Not sure what reason causing this error.
Check your environment whether these things have been set up.
I think it might be your config type is wrong.
npm install hexo-deployer-git --save
git repository settings like
deploy:
- type: git
repo: git#github.com:xxx.git
branch: master
- type: git
repo: git#github.com:xxx.git
branch: src
extend_dirs: /
ignore_hidden: false
ignore_pattern:
public: .
By this way, you can not only deploy your blog, but also backup your blog files, which you can use the command git pull to get the blog files on another machine.
- set up your ssh
ssh-keygen -t rsa -C "yourEmail#icloud.com"
ssh-agent -s
chmod id_rsa 600
ssh-add id_rsa
(you need to add the id_rsa.pub to the github's deployer key)
ssh -T git#github.com
sometimes it maybe you have several gits, make deployer confused.
Try delete .git directory and make sure there is no any git in other directories.
encoding. It could be the encoding is different. In my case, I make all the files belong to UTF-8.
By the way, it could be your files' error.try npm install hexo-server --save and hexo server to detect whether the website can be deployed.
(http://localhost:4000/xx)
I am using the Gitolite to create the git repo.
I have requirement that when user push something to repo it must have some specific file (eg. .md file) otherwise don't let push the code.
So now I need to configure a post-push hook and do some operation on pushed content.
Can any one please help me to do the same?
First, I would not recommend gitosis (old and obsolete).
Second, this is a job for a VREF (update hooks in Gitolite lingo).
You can use in that VREF a diff --name-only or diff --name-status:
git diff --name-only <sha-old> <sha-new>
(See shell explained)
If the list doesn't include your .md file, you would exit with a non-zero status, and the git push would be denied.
My firm is setting up Gitolite on Linux and we would like to setup a backup for the server just in case of a crash on every commit to a 2nd Linux server.
How can we backup a Gitolite server on every commit to it? Is anyone doing this?
Another way to generate backups is to ask your post-receive hook to create a bundle (a bit like in this question)
!/bin/sh
git bundle create "/path/to/backup/$(basename "$PWD").bundle" --branches --tags
This is based on the fact that hook runs in a bare repo: see "how to get project path in hook script post-commit?".
The interest in bundle and git bundle is that is generates only one file, which is easier to manage/copy around.
And that fact acts as a (mostly read-only) repo, meaning you can clone from that file.
This would work:
git clone myrepo.bundle myrepo
See also:
"git bundle: bundle tags and heads",
"Backup a Local Git Repository", and
"Git with Dropbox".
First you should not worry too much about git backups. - Everyone who is working in your project will have a complete clone on his box. - Hence more than enough backups. ;)
But you want to have another official repository updated after each push. In this case probably the easiest way is writing a small server side hook, that runs after each push and itself pushes the changes to the second repository.
You probably want to use a post-receive hook. For details have a look at here or here.
Example:
#create repositories
git init a
git init --bare b
git init --bare c
#add the hook in "b"
echo -e '#!/usr/bin/bash\nread old new ref\ngit push ../c $ref' >>b/hooks/post-receive
chmod +x b/hooks/post-receive
#create a commit in "a"
cd a
echo foo >test
git add .
git commit -m testcommit
#push it to "b"
git push ../b master
#notice the "remote:..." output of the hook
#find the commit in "c"
cd ../c
git log
This creates three repositories. When you have a commit in a and push it to b the hook will push it to c, too.
I'm wondering is there a simple way to install hooks for certain repo using gitolite_admin.
Let's imagine i want to have post-update hook for repo awesome using gitolite_admin repo cloned to my workstation...
#conf/gitolite_conf
repo awesome
RW+ = deployer
contents of post-update:
#!/bin/sh
echo "Post receive-hook => updating Redmine repository"
sudo -u deployer perl -we '`cd /home/deployer/repo/awesome.git && git fetch -q --all`'
You could also look at "repo-specific environment variables"
A special form of the option syntax can be used to set repo-specific environment variables that are visible to gitolite triggers and any git hooks you may install.
For example, let's say you installed a post-update hook that initiates a CI job. By default, of course, this hook will be active for all gitolite-managed repos. However, you only want it to run for some specific repos, say r1, r2, and r4.
To do that, first add this to the gitolite.conf:
repo r1 r2 r4
option ENV.CI = 1
This creates an environment variable called GL_OPTION_CI with the value 1, before any trigger or hook is invoked.
Note: option names must start with ENV., followed by a sequence of characters composed of alphas, numbers, and the underscore character.
Now the hook running the CI job can easily decide what to do:
# exit if $GL_OPTION_CI is not set
[ -z $GL_OPTION_CI ] && exit
... rest of CI job code as before ...
Of course you can also do the opposite; i.e. decide that the listed repos should not run the CI job but all other repos should:
repo #all
option ENV.CI = 1
repo r1 r2 r4
option ENV.CI = ""
That feature is fairly recent (started in commit 999f9cd39, but in this case, completed in commit 63865a16 June 2013 for 3.5.2).
But even you don't have that version, there are other ways to do this using option variables, as the last part of that section explains.
Before this feature was added, you could still do this, by using the gitolite git-config command inside the hook code to test for options and configs set for the repo, like:
if gitolite git-config -q reponame gitolite-options.option-name
then
...
And you can use git config variables in the same way.
Or you can use group membership -- see the comments against function "in_group" in "Easy.pm" for details.
# in_group()
# return true if $ENV{GL_USER} is set and is in the given group
# shell equivalent
# if gitolite list-memberships $GL_USER | grep -x $GROUPNAME >/dev/null; then ...
In addition to sitaram's answer, the recent (August 29th, 2013) commit 62fb31755a formerly introduce repo specific hooks:
it's basically just creating a symlink in <repo.git>/hooks pointing to some file inside $rc{LOCAL_CODE}/hooks/repo-specific (except the gitolite-admin repo)
You cannot specific a hook for gitolite-admin though.
And you hook is only one of the three following authorized hooks:
pre-receive
post-receive
post-update
That means you can:
store your repo specific hooks in your gitolite-admin/hooks/repo-specific/xx
declare those your in the gitolite-admin local options on the server.
First enable those hooks:
ENABLE => [
# allow repo-specific hooks to be added
# 'repo-specific-hooks',
Then declare the hooks on the server gitolite-admin repo:
gitolite git-config gitolite-options.hook=reponame hookname scriptname
(with a tab or \t between reponame hookname scriptname)
Original answer:
As mention in the gitolite man page on hooks
if you want to install a hook in only a few specific repositories, do it directly on the server.
(otherwise, you would be managing hooks for all git repos through gitolite-admin/common/hooks)
That being said, you could take advantage of VREF in gitolite V3.x, which are update hooks: those can be set for some repos and for some user, like any other rule.
You could then:
make your VREF script leave a 'flag' (a file) in the appropriate bare git repo being updated
make a common 'deploy' post-update hook, which would first look for that flag, and if found, deploy the repo (and remove the flag).
Again:
a post-update hook managed through gitolite-admin can only be common to all git repos (not what you want)
only VREFs can be associated to repos and users through gitolite.conf
The solution above tries to take those two facts into account to achieve what you are looking for: a deploy script running only for certain repos and managed through the gitolite.conf config file of the gitolite-admin repo.
Here are step by step instructions to complement #VonC's answer
gitolite hook for specific repository