Proposal: Updating the binary version automatically via shell script #13015
Comments
|
This might be a nice thing to add to awesome-gitea. 🙂 |
|
From 1.13 we should recommend flushing the queues before upgrading too. |
You mean |
|
Yes |
|
Alright! I would like to implement this, but it returns an error: $ gitea manager flush-queues
Gitea: InternalServerError
Unable to contact gitea: Post "http://localhost:3000/api/internal/manager/flush-queues": dial tcp [::1]:3000: connect: connection refusedI could not find any process listening to $ ss -tulpan | grep "3000"How do I configure this? |
|
As with all gitea commands you will need to provide it with a config - so set the |
|
Ah, of course! I totally forgot about this... I tried different parameter positions and also set the log level to $ gitea manager flush-queues --config /etc/gitea/app.ini
$ echo "${?}"
1What am I doing wrong?
APP_NAME = Gitea: Git with a cup of tea
RUN_USER = gitea
RUN_MODE = prod
[oauth2]
JWT_SECRET = <some_secret>
[security]
INTERNAL_TOKEN = <some_token>
INSTALL_LOCK = true
SECRET_KEY = <some_token>
# custom - 20191103 - rfischer: set "PASSWORD_HASH_ALGO" to "pbkdf2"
PASSWORD_HASH_ALGO = pbkdf2
[server]
# LOCAL_ROOT_URL = http://localhost:80/
# HTTP_PORT = 80
SSH_DOMAIN = gitea.local
DOMAIN = gitea.local
#ROOT_URL = http://gitea.local/
DISABLE_SSH = false
SSH_PORT = 22
LFS_START_SERVER = true
LFS_CONTENT_PATH = /var/lib/gitea/data/lfs
LFS_JWT_SECRET = <some_secret>
OFFLINE_MODE = true
# custom - 20191103 - rfischer: enable tls
LOCAL_ROOT_URL = https://localhost/
PROTOCOL = https
ROOT_URL = https://gitea.local/
HTTP_PORT = 443
CERT_FILE = /etc/gitea/tls/gitea.local/gitea.local.crt
KEY_FILE = /etc/gitea/tls/gitea.local/gitea.local.key
# custom - 20191103 - rfischer: set further settings
ENABLE_GZIP = true
[database]
DB_TYPE = sqlite3
HOST = <some_ip_address>:<some_port_number>
NAME = gitea
USER = gitea
#PASSWD =
# custom - 20191103 - rfischer: set a database password
PASSWD = <some_password>
SSL_MODE = disable
CHARSET = utf8
PATH = /var/lib/gitea/data/gitea.db
[repository]
ROOT = /home/gitea/gitea-repositories
# custom - 20190105 - rfischer: prefer a better formatted apache2.0 license file
PREFERRED_LICENSES = Custom_Apache-2.0
# custom - 20191103 - rfischer: add "[repository.pull-request]"
[repository.pull-request]
WORK_IN_PROGRESS_PREFIXES = WIP:, [WIP]
CLOSE_KEYWORDS = close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved
REOPEN_KEYWORDS = reopen, reopens, reopened
# custom - 20191103 - rfischer: add "[repository.issue]"
[repository.issue]
LOCK_REASONS = too heated, off-topic, resolved, spam
# custom - 20191103 - rfischer: add "[ui]"
[ui]
DEFAULT_THEME = arc-green
# custom - 20191103 - rfischer: add "[markdown]"
[markdown]
CUSTOM_URL_SCHEMES = ftp, git, svn, rsync
[mailer]
ENABLED = false
[service]
REGISTER_EMAIL_CONFIRM = false
ENABLE_NOTIFY_MAIL = false
#DISABLE_REGISTRATION = false
# custom - 20200102 - rfischer: disable registration
DISABLE_REGISTRATION = true
ALLOW_ONLY_EXTERNAL_REGISTRATION = false
ENABLE_CAPTCHA = false
REQUIRE_SIGNIN_VIEW = false
DEFAULT_KEEP_EMAIL_PRIVATE = false
DEFAULT_ALLOW_CREATE_ORGANIZATION = true
DEFAULT_ENABLE_TIMETRACKING = true
NO_REPLY_ADDRESS = noreply.example.org
[picture]
DISABLE_GRAVATAR = true
ENABLE_FEDERATED_AVATAR = false
[openid]
ENABLE_OPENID_SIGNIN = false
ENABLE_OPENID_SIGNUP = false
[session]
PROVIDER = file
# custom - 20191103 - rfischer: add "[attachment]"
[attachment]
ALLOWED_TYPES = */*
[log]
MODE = file
LEVEL = trace
ROOT_PATH = /var/log/gitea |
|
@zeripath Is the flush a necessary step to upgrade? |
|
potentially yes - the idea is that you would clean up all waiting tasks before you upgraded. Imagine a situation whereby the pull model struct is completely changed then when you restore from the queue list you won't be able to map that back. It's that kind of thing. I don't think we've made any significant changes that would break anything - but it's possible. |
|
@keks24 is the server also running? What do the logs from the server say? Are you running master? (This command is only available on master) What does |
$ systemctl status gitea
● gitea.service - Gitea (Git with a cup of tea)
Loaded: loaded (/etc/systemd/system/gitea.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-10-03 13:45:39 UTC; 1 day 12h ago
Main PID: 4926 (gitea)
Tasks: 13 (limit: 4915)
Memory: 251.6M
CGroup: /system.slice/gitea.service
└─4926 /usr/local/sbin/gitea web --config /etc/gitea/app.ini
Oct 05 01:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 01:00:02: Started POST /api/internal/ssh/8/update/15 for [::1]
Oct 05 01:00:03 gitea gitea[4926]: [Macaron] 2020-10-05 01:00:03: Completed POST /api/internal/ssh/8/update/15 200 OK in 569.851305ms
Oct 05 02:00:01 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:01: Started GET /api/internal/serv/command/8/keks24/documentation?mode=1&verb=git-upload-pack for [::1]
Oct 05 02:00:01 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:01: Completed GET /api/internal/serv/command/8/keks24/documentation?mode=1&verb=git-upload-pack 200 OK in 1.489687ms
Oct 05 02:00:01 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:01: Started POST /api/internal/ssh/8/update/15 for [::1]
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Completed POST /api/internal/ssh/8/update/15 200 OK in 373.611925ms
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Started GET /api/internal/serv/command/8/keks24/documentation?mode=1&verb=git-upload-pack for [::1]
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Completed GET /api/internal/serv/command/8/keks24/documentation?mode=1&verb=git-upload-pack 200 OK in 1.059409ms
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Started POST /api/internal/ssh/8/update/15 for [::1]
Oct 05 02:00:02 gitea gitea[4926]: [Macaron] 2020-10-05 02:00:02: Completed POST /api/internal/ssh/8/update/15 200 OK in 161.137996ms
[log]
MODE = file
LEVEL = trace
ROOT_PATH = /var/log/giteaSetting
$ gitea manager -c /etc/gitea/app.ini flush-queues --debug
Incorrect Usage: flag provided but not defined: -debug
NAME:
Gitea manager flush-queues - Flush queues in the running process
USAGE:
Gitea manager flush-queues [command options] [arguments...]
OPTIONS:
--timeout value Timeout for the flushing process (default: 1m0s)
--non-blocking Set to true to not wait for flush to complete before returning
--custom-path value, -C value Custom path file path (default: "/usr/local/sbin/custom")
--config value, -c value Custom configuration file path (default: "/usr/local/sbin/custom/conf/app.ini")
--version, -v print the version
--work-path value, -w value Set the gitea working path (default: "/usr/local/sbin")
DEFAULT CONFIGURATION:
CustomPath: /usr/local/sbin/custom
CustomConf: /etc/gitea/app.ini
AppPath: /usr/local/sbin/gitea
AppWorkPath: /usr/local/sbin
2020/10/05 02:31:58 main.go:111:main() [F] Failed to run app with [gitea manager -c /etc/gitea/app.ini flush-queues --debug]: flag provided but not defined: -debugIt seems, that there is no gitea --help
NAME:
Gitea - A painless self-hosted Git service
USAGE:
gitea [global options] command [command options] [arguments...]
VERSION:
1.12.5 built with GNU Make 4.1, go1.14.9 : bindata, sqlite, sqlite_unlock_notify
DESCRIPTION:
By default, gitea will start serving using the webserver with no
arguments - which can alternatively be run by running the subcommand web.
COMMANDS:
web Start Gitea web server
serv This command should only be called by SSH shell
hook Delegate commands to corresponding Git hooks
dump Dump Gitea files and database
cert Generate self-signed certificate
admin Command line interface to perform common administrative operations
generate Command line interface for running generators
migrate Migrate the database
keys This command queries the Gitea database to get the authorized command for a given ssh key fingerprint
convert Convert the database
doctor Diagnose problems
manager Manage the running gitea process
embedded Extract embedded resources
help, h Shows a list of commands or help for one command
GLOBAL OPTIONS:
--port value, -p value Temporary port number to prevent conflict (default: "3000")
--pid value, -P value Custom pid file path (default: "/var/run/gitea.pid")
--custom-path value, -C value Custom path file path (default: "/usr/local/sbin/custom")
--config value, -c value Custom configuration file path (default: "/usr/local/sbin/custom/conf/app.ini")
--version, -v print the version
--work-path value, -w value Set the gitea working path (default: "/usr/local/sbin")
--help, -h show help
DEFAULT CONFIGURATION:
CustomPath: /usr/local/sbin/custom
CustomConf: /usr/local/sbin/custom/conf/app.ini
AppPath: /usr/local/sbin/gitea
AppWorkPath: /usr/local/sbinWithout $ gitea manager -c /etc/gitea/app.ini flush-queues
$ echo "${?}"
1Edit - 20201005 - 0518: I found the issue. I have to execute $ ps aux | grep "gitea"
[...]
gitea 646 0.0 18.4 1534440 193968 ? Ssl 02:35 0:08 /usr/local/sbin/gitea web --config /etc/gitea/app.ini$ su - gitea
$ printenv GITEA_CUSTOM GITEA_WORK_DIR
/etc/gitea/
/var/lib/gitea/
$ gitea manager flush-queues
Flushed
I always executed the commands as the user Is it safe, to flush queues with |
|
All flush-queues does is connect to the Gitea server on an internal web endpoint. It simply needs the correct environment and the correct config. It doesn't matter which user calls it - it would likely be safe as root. I didn't realise that you were on 1.12, 1.13 will have better debugging and should give you a better report of the error - I'm not certain what could have been going wrong there. (I'd also forgotten that flush-queues was in 1.12!) |
|
Alright! So, I should be able to execute one of the following commands as user $ gitea manager flush-queues --custom-path="/etc/gitea/" --work-path="/var/lib/gitea/" --config="/etc/gitea/app.ini"
$ gitea manager flush-queues --custom-path "/etc/gitea/" --work-path "/var/lib/gitea/" --config "/etc/gitea/app.ini"
$ gitea manager flush-queues -C "/etc/gitea/" -w "/var/lib/gitea/" -c "/etc/gitea/app.ini"
$ gitea manager flush-queues -C /etc/gitea/ -w /var/lib/gitea/ -c /etc/gitea/app.ini
$ gitea manager flush-queues -C /etc/gitea -w /var/lib/gitea -c /etc/gitea/app.iniI am trying to mimic the configuration of $ su - gitea
$ gitea --help
[...]
DEFAULT CONFIGURATION:
CustomPath: /etc/gitea/ (GITEA_CUSTOM)
CustomConf: /etc/gitea/conf/app.ini
AppPath: /usr/local/sbin/gitea
AppWorkPath: /var/lib/gitea/
$ logoutBut it does not work. It just exits again: $ echo "${?}"
1Even exporting the variables does not solve this: $ export GITEA_CUSTOM="/etc/gitea/"
$ export GITEA_WORK_DIR="/var/lib/gitea/"I am blind right now and cannot see what I am missing. |
|
A log.Fatal is, in all likelihood, occurring within setting.NewContext - which because the console logger has been completely disabled - is not appearing. I don't know where or which but that's why I've put the Thinking on the correct thing to do is probably not to delete the console logger but set it to still print out fatals (See #13032). However, that won't be backportable really. |
Fair enough. I would not expect to have a backport or something, since it would cause more work to maintain Gitea. I will keep the current solution to run the command as Thank you for your efforts! By the way: |
|
There are a number of Ansible roles on Galaxy that might be useful, including mine (on.gitea). I use it to install or upgrade gitea. Feedback welcome. |
|
Another script provided by noerw: |
|
The updater command has been merged. |
Description
Hello,
I wrote a shell script to update my local Gitea instance automatically. I would like to leave this here, so others have a use of it.
Currently it only downloads the
amd64binary version fromGitHub. Others may make it more dynamic.Maybe it is useful and stable enough to mentioning it here or put it into the
contribdirectory?Prerequisites:
The following packages are installed:
An example:
I have not created a GPG keyring on my server and also not signed Gitea's GPG public key with my private key, so the check returns a warning, but better than nothing!
The files are downloaded to
/usr/local/share/gitea/<some_version>-<some_os>-<some_arch>/. There is no cleanup routine implemented and must be done manually:$ tree . ├── 1.12.4-linux-amd64/ │ ├── gitea-1.12.4-linux-amd64 │ ├── gitea-1.12.4-linux-amd64.asc │ └── gitea-1.12.4-linux-amd64.sha256 └── 1.12.5-linux-amd64/ ├── gitea-1.12.5-linux-amd64 ├── gitea-1.12.5-linux-amd64.asc └── gitea-1.12.5-linux-amd64.sha256 2 directories, 6 filesUpdating the same version once again, skips the download:
Screenshots
The text was updated successfully, but these errors were encountered: