rewrite pre-commit, post-commit and options hooks (fixes #1250) #1257
Conversation
…e shell script that does not require custom hooks to be a sh-script
models/repo.go
Outdated
| fmt.Sprintf("#!/usr/bin/env %s\nORI_DIR=`pwd`\nSHELL_FOLDER=$(cd \"$(dirname \"$0\")\";pwd)\ncd \"$ORI_DIR\"\nfor i in `ls \"$SHELL_FOLDER/update.d\"`; do\n sh \"$SHELL_FOLDER/update.d/$i\" $1 $2 $3\ndone", setting.ScriptType), | ||
| fmt.Sprintf("#!/usr/bin/env %s\nORI_DIR=`pwd`\nSHELL_FOLDER=$(cd \"$(dirname \"$0\")\";pwd)\ncd \"$ORI_DIR\"\nfor i in `ls \"$SHELL_FOLDER/post-receive.d\"`; do\n sh \"$SHELL_FOLDER/post-receive.d/$i\"\ndone", setting.ScriptType), | ||
| } | ||
| hookTpl = fmt.Sprintf("#!/usr/bin/env %s\ndata=$(cat)\nexitcodes=()\nhookname=$(basename $0)\nGIT_DIR=${GIT_DIR:-$(dirname $0)}\n\nfor hook in ${GIT_DIR}/hooks/${hookname}.d/*; do\ntest -x \"${hook}\" || continue\necho \"${data}\" | \"${hook}\"\nexitcodes+=($?)\ndone\n\nfor i in \"${exitcodes[@]}\"; do\n[ \"${i}\" == 0 ] || exit ${i}\ndone\n", setting.ScriptType) |
There was a problem hiding this comment.
bash-specific syntax ($(cat)) in what could be running with something else (setting.ScriptType).
Not that I understand how can Gitea possibly contains code to be run by unknown scripts, anyway the app.ini Cheat Sheet says ScriptType is usually bash or sh...
There was a problem hiding this comment.
data=$(cat) is not bash-specific.
bash can be run in posix mode when either invoking the script either using sh (sh scriptname, sh in shebang) or by using the switch --posix (or using set -o posix in the script itself). Tried both of it, script worked fine. Even though myarray=() is a bashism.
Some Debian systems might symlink /bin/sh to /bin/dash (the Debian Almquist Shell), so we might want to force using bash in this case.
Or, to make it more posix-compliant, give up on arrays:
#!/bin/sh
data=$(cat)
exitcodes=""
hookname=$(basename $0)
GIT_DIR=${GIT_DIR:-$(dirname $0)}
for hook in ${GIT_DIR}/hooks/${hookname}.d/*; do
test -x "${hook}" || continue
echo "${data}" | "${hook}"
exitcodes="${exitcodes} $?"
done
for i in ${exitcodes}; do
[ $i -eq 0 ] || exit $i
done(tested with dash)
|
Why we can't create symlink for hooks to gitea binary? In this case we
don't need bash, sh and other stuff. And gitea handle hook internally.
15 Мар 2017 г. 9:29 пользователь "Sandro Santilli" <notifications@github.com>
написал:
… ***@***.**** requested changes on this pull request.
I see you're feeding a bash script to a user-configurable scriptType,
sounds fragile to me. Can you us a POSIX syntax please ?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1257 (review)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAdYG9TihPxRzcXJdX42SJmwKrkEb0KBks5rl4UugaJpZM4MdRlY>
.
|
tboerger
added
the
lgtm/need 2
|
I dunno why are you talking about symlinks, but yes I think we could just invoke the commands, if executables. But please make sure you touch all files containing that bash invocation, I see 3 places. |
|
Am I missing something? The |
|
Yes, the migrations. I'm not very sure what are them for, and how to effectively test them, will be tricky. |
|
The migrations will be simple to rewrite all the scripts. But don't forget wiki repo's hooks. |
|
afaics the wiki pages use the same hooks as the repos do. Which leads to funny side-effects[1] but that's not relevant here. I'm a little concerned about the migration scripts. In my understanding the scripts should update database schemas, scripts (i.e. hooks) and other stuff that might have changed between gitea versions. edit [1] I have |
|
Good question about migrations. I think first step is understanding what those migrations did in |
|
the migration works for me.
|
|
As @strk pointed out, don't touch existing migrations, it will break things even worse. Create a new migration that updates all existing hooks. |
|
@bkcsoft I did not touch existing migrations. |
| @@ -0,0 +1,83 @@ | |||
| package migrations | |||
models/migrations/migrations.go
Outdated
| @@ -100,6 +100,8 @@ var migrations = []Migration{ | |||
| NewMigration("change the key_id and primary_key_id type", changeGPGKeysColumns), | |||
| // v25 -> v26 | |||
| NewMigration("add show field in user openid table", addUserOpenIDShow), | |||
| // v26 -> v27 | |||
| NewMigration("generate and migrate repo and wiki Git hooks", generateAndMigrateGitHookChains), | |||
There was a problem hiding this comment.
Run make fmt should be enough (and we need our bot to guard after this, I may give that a try)
|
And maybe you can also fix another issue This function didn't sync wiki repository's hooks. |
|
otherwise LGTM |
tboerger
added
lgtm/need 1
|
So doesn't it take any migration to fix the existing hooks ? How/when do those wrapper scripts get installed in git repos ? |
|
@strk I'm not sure what you're talking about. Actually there is a migration script ( @lunny |
|
@philfry sorry I think I was fooled by github as when I wrote that comment I really didn't see the migration file ! LGTM (trusted, didn't really test it) |
tboerger
added
lgtm/done
|
@philfry, could you send a backport PR to v1.1? But maybe the migrations is difficult to handle. |
…t and options hooks (#1376) * issue #1250, replace {pre,post}-receive and update hooks with a single shell script that does not require custom hooks to be a sh-script * issue #1250, make script posix compilant * v23, add migration script to update {pre,post}-receive and update hooks * migration: use a more common name and rename v23 to v26 to avoid conflicts * gofmt'ed and added copyright header * fix SyncRepositoryHooks to also sync wiki repos * no migration for you.
see #1250