Still use GOGS_WORK_DIR and GOGS_CUSTOM env variables
as a fallback if the equivalent GITEA_* are not set,
warning user about the need for change.
Does not change "gogs" to "gitea" in webhook type name
Because "gogs" hook type is part of the API (routes) and used
in templates...
Closes#87
Using this script:
1. Copy scripts/launchd/io.gogs.web.plist into /Library/LaunchDaemons
2. The script assumes Gogs is running under 'gogs' user and group, modify
/Library/LaunchDaemons/io.gogs.web.plist if you want to user different user.
3. The script assumes Gogs is installed in /Users/git/gogs, modify
/Library/LaunchDaemons/io.gogs.web.plist if you installed Gogs in different
location.
4. Once you are sure that running Gogs manually via `gogs web` works fine, run
it as a launchd service with:
sudo launchctl load -F /Library/LaunchDaemons/io.gogs.web.plist
From now on launchd will ensure Gogs is running, eg. when system is restarted.
If the init script is called with `status`, the rc.subr(8) routines check if
the first argument associated with the pid in the pidfile is equal to
`procname`. By default, `procname` is equal to the value of `command`. In our
case, `command` contains a space (i.e. has multiple arguments), so `procname`
can never be equal to the first argument of the command associated with the
pid.
Set `procname` to the first argument of `command` to fix the `status` command
of the init script.
- use start-stop-daemon's chuid feature insted of su
- using `su -c` breaks if the git user has no usable shell
- this fixes#1025
- put --test before --exec, instead it gets passed to gogs
- set cwd via --chdir
This change to start.sh allows it to be executed from any working directory and always reference the gogs binary in the parent directory. Very helpful when calling start.sh from an init script.