cmiksche / gitea-auto-update Goto Github PK

It would be nice if there was a post update hook option in the settings so we could enter a command to run after successfully updating gitea. Currently I use a systemd daily timer unit to run the updater so I'm just doing a post there of systemctl restart gitea. The downside is that this restarts gitea regardless on if an update was performed or not which may cause issues if someone is currently interacting with a repo far more often than it should.

The bot created this issue to inform you that pyup.io has been set up on this repo.
Once you have closed it, the bot will open pull requests for updates as soon as they are available.

With a update of gitea there can be changes in the templates.
E.g. the path to JavaScript Files are changed.

If you don't use custom gitea templates then that's not a problem but if you copied the default template and changed it - then you have a problem because e.g. your template references to JS-Files which doesn't exist anymore.

To fix that this tool could automatically update your customized gitea templates with the new version. But it should keep your changes.

First, thank you for sharing this script!

I'm unable to get the script working due to API access restrictions. Looking through information on API calls, I've attempted generating access tokens and using them in my Gitea instance URL. Unfortunately, that doesn't work either, perhaps because I have multi-factor authentication enabled.

If I attempt to access the API version call itself via WGET, I get the following error:
2019-05-27 17:24:38 ERROR 403: Forbidden.

When I run upater.py, I get the following error:

/u/l/b/gitea $ sudo python3 gitea-auto-update/updater.py 
Traceback (most recent call last):
  File "gitea-auto-update/updater.py", line 19, in <module>
    current_version = requests.get(settings.gtsite).json()['version']
KeyError: 'version'

Would it be worthwhile to amend the script to simply use the Gitea executable for version check?

/u/l/b/gitea $ ./gitea -v
Gitea version 1.8.0 built with go1.12.4 : bindata, sqlite, sqlite_unlock_notify

Dependabot couldn't authenticate with https://pypi.org/simple/.

You can provide authentication details in your Dependabot dashboard by clicking into the account menu (in the top right) and selecting 'Config variables'.

View the update logs.

Hi there, i just want to install this in CentOS, but cannot do it through Readme here.

Thanks

Current Gitea version: 1.15.10

/usr/local/bin/gitea-auto-update --settings=/home/git/update/settings.ini
sha256sum: gitea.xz.sha256: no properly formatted SHA256 checksum lines found

How to fix this issue?

See GH-1:

the updater is also missing any sort of verification, such as implemented here: https://gist.github.com/HorlogeSkynet/d676b9204869842933169dbe35ed8650 If this code is still in use, it might be good to implement something similar.

It's possible to automatically publish to PyPI using the pypi-publish Action.

That would enable a automatic way for publishing this package.

Is your feature request related to a problem? Please describe.
Updating to the most recent release is potentially not always desired.

Describe the solution you'd like
I think it would be nice to have a CLI option that allows to install a specific version by version tag. This could look like the following to install version 1.13.6 instead of 1.14.1, which is as of now the latest release:

gitea-auto-update -v 1.13.6

Or maybe even pinning to a minor version, where the following would install the latest bug-fix release of 1.13:

gitea-auto-update -v 1.13

Describe alternatives you've considered
Do not see any.

Additional context
None.

The version comparison does not match semver, which I assume is what Gitea follows. The code seems to do a string comparison, but whereas 1.10.0 would be more recent than 1.9.0 following semver, in string comparisons, the 9 comes after the 1 and so it would say 1.10.0' > '1.9.0' == False.

I think this should fix it:

map(int, newver.split('.')) > map(int, oldver.split('.'))

The issue with that code is that it will not support any sort of suffix, like 2.0.0-rc1. It seems those are always marked as pre-releases anyway so this should never happen when pulling the latest release, but it might still be good to have some sort of fallback for that, such as emailing the sysadmin.

The current code will only ever bug when any part of the version number (major, minor, patch) exceeds 9, and Gitea has not done that so far, but for an automatic updater that is meant to be forgotten, this might not be the best behaviour :)

By the way, I don't want to open a bunch of issues (feels like criticism), so I'll just mention it here instead: the updater is also missing any sort of verification, such as implemented here: https://gist.github.com/HorlogeSkynet/d676b9204869842933169dbe35ed8650 If this code is still in use, it might be good to implement something similar.

Travis CI will limit the number of build minutes in the future, Drone CI won't and I already use Drone CI in other projects.

So I should migrate this project to Drone CI

Describe the bug
Hi,
On systems running SELinux (Centos in my case) the update fails after the gitea service is restarted.

To Reproduce
Steps to reproduce the behavior:

1. Run gitea-auto-update
2. Restart gitea
3. See the following errors in logs:
   gitea.service: Failed to execute command: Permission denied
   gitea.service: Failed at step EXEC spawning /usr/local/bin/gitea: Permission denied

Expected behavior
gitea starts after upgrade without additional steps/troubleshooting.

Additional context
Running restorecon on the file fixes the issue...
[root@git01 ~]# restorecon -v /usr/local/bin/gitea Relabeled /usr/local/bin/gitea from unconfined_u:object_r:user_tmp_t:s0 to unconfined_u:object_r:bin_t:s0

Alternatively I believe if the file is copied from the tmp folder instead of moved the original context does not remain with the file...

Sometimes release candidates can be helpful if someone e.g. want to use new upcoming features right now.

However the current project only checks and updates stable releases.

This option could be realized with a CLI flag like --rc=True or a new setting in the config file. It should default to false.

See GH-1:

The issue with that code is that it will not support any sort of suffix, like 2.0.0-rc1. It seems those are always marked as pre-releases anyway so this should never happen when pulling the latest release, but it might still be good to have some sort of fallback for that, such as emailing the sysadmin.

Describe the bug
I am getting a permission denied error when trying to run this inside TurnkeyLinux Gitea LXC.

https://www.turnkeylinux.org/gitea

To Reproduce

root@gitea ~# gitea-auto-update --settings=/home/git/update/settings.ini
/bin/sh: 1: /home/git/: Permission denied
Traceback (most recent call last):
  File "/usr/local/lib/python3.7/dist-packages/gitea_auto_update/lib/version.py", line 48, in get_current_version
    current_version = self.get_version_from_file()
  File "/usr/local/lib/python3.7/dist-packages/gitea_auto_update/lib/version.py", line 42, in get_version_from_file
    return parse_file_version(version_string)
  File "/usr/local/lib/python3.7/dist-packages/gitea_auto_update/lib/version.py", line 24, in parse_file_version
    return string.split(" ")[2]
IndexError: list index out of range

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/bin/gitea-auto-update", line 10, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.7/dist-packages/gitea_auto_update/update.py", line 90, in main
    fire.Fire(updater)
  File "/usr/local/lib/python3.7/dist-packages/fire/core.py", line 141, in Fire
    component_trace = _Fire(component, args, parsed_flag_args, context, name)
  File "/usr/local/lib/python3.7/dist-packages/fire/core.py", line 471, in _Fire
    target=component.__name__)
  File "/usr/local/lib/python3.7/dist-packages/fire/core.py", line 681, in _CallAndUpdateTrace
    component = fn(*varargs, **kwargs)
  File "/usr/local/lib/python3.7/dist-packages/gitea_auto_update/update.py", line 83, in updater
    Update(config)
  File "/usr/local/lib/python3.7/dist-packages/gitea_auto_update/update.py", line 35, in __init__
    self.check_and_update()
  File "/usr/local/lib/python3.7/dist-packages/gitea_auto_update/update.py", line 62, in check_and_update
    current_version = version.get_current_version()
  File "/usr/local/lib/python3.7/dist-packages/gitea_auto_update/lib/version.py", line 59, in get_current_version
    logging.info('Version: current_version = %s', current_version)
UnboundLocalError: local variable 'current_version' referenced before assignment

Thanks for any assistance.

#1
current logic:

python3 updater.py # only if logic
current_version = 1.9.0+dev-264-g8de76b6e6
current_version = 1.9.0
github_version_tag = v1.8.1
[1, 8, 1]   [1, 9, 0]
1   1
False
8   9
False
1   0
True
True

tested with:

def checkVersion(new_version, old_version):
    new_version_list = getVersionList(new_version)
    old_version_list = getVersionList(old_version)
    print (new_version_list, " ", old_version_list)

    for id, val in enumerate(new_version_list):
        print (val, " ", old_version_list[id])
        if val > old_version_list[id]:
           print ("True") 
           return True
        else:
            print ("False")
    return None

[:5], can be used to filter excess letters, from dev version.
string.replace(".", "") , can be used and go back to the old version.

I have this so far:

[Gitea]
site=https://git.codifyde.org/api/v1/version
apiUrl=https://api.github.com/repos/go-gitea/gitea/releases/latest
system=linux-amd64
file=/usr/local/bin/gitea
tmpDir=/tmp/
buildFromSource=None
sourceDir=
logFile=update.log

Where can I locate the sourceDir for this? Am wanting to update Gitea.

Describe the bug
I got following error message: ~$ ```
gitea-auto-update --settings=/home/kovacsa/settings.ini
Traceback (most recent call last):
File "/usr/local/bin/gitea-auto-update", line 11, in
load_entry_point('gitea-auto-update==2.0.5', 'console_scripts', 'gitea-auto-update')()
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 480, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 2693, in load_entry_point
return ep.load()
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 2324, in load
return self.resolve()
File "/usr/lib/python2.7/dist-packages/pkg_resources/init.py", line 2330, in resolve
module = import(self.module_name, fromlist=['name'], level=0)
File "/usr/local/lib/python2.7/dist-packages/gitea_auto_update/update.py", line 14, in
import gitea_auto_update.lib.download
File "/usr/local/lib/python2.7/dist-packages/gitea_auto_update/lib/download.py", line 12, in
from shutil import which # from whichcraft import which
ImportError: cannot import name which

**To Reproduce**
Steps to reproduce the behavior:
I issued `gitea-auto-update --settings=/home/kovacsa/settings.ini` command to set location of settings file.