1
0
Fork 0
mirror of https://github.com/YunoHost-Apps/fittrackee_ynh.git synced 2024-09-03 18:36:16 +02:00

Merge pull request #3 from oufmilo/testing

Testing
This commit is contained in:
oufmilo 2022-12-21 22:21:21 +01:00 committed by GitHub
commit 6e3a8fadc8
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
4 changed files with 64 additions and 115 deletions

View file

@ -9,9 +9,6 @@
# Since each app is different, maintainers can adapt its contents so as to perform
# automatic actions when a new upstream release is detected.
# Remove this exit command when you are ready to run this Action
exit 1
#=================================================
# FETCHING LATEST RELEASE AND ITS ASSETS
#=================================================
@ -21,13 +18,13 @@ current_version=$(cat manifest.json | jq -j '.version|split("~")[0]')
repo=$(cat manifest.json | jq -j '.upstream.code|split("https://github.com/")[1]')
# Some jq magic is needed, because the latest upstream release is not always the latest version (e.g. security patches for older versions)
version=$(curl --silent "https://api.github.com/repos/$repo/releases" | jq -r '.[] | select( .prerelease != true ) | .tag_name' | sort -V | tail -1)
assets=($(curl --silent "https://api.github.com/repos/$repo/releases" | jq -r '[ .[] | select(.tag_name=="'$version'").assets[].browser_download_url ] | join(" ") | @sh' | tr -d "'"))
assets="https://github.com/bookwyrm-social/bookwyrm/archive/refs/tags/$version.tar.gz"
# Later down the script, we assume the version has only digits and dots
# Sometimes the release name starts with a "v", so let's filter it out.
# You may need more tweaks here if the upstream repository has different naming conventions.
# You may need more tweaks here if the upstream repository has different naming conventions.
if [[ ${version:0:1} == "v" || ${version:0:1} == "V" ]]; then
version=${version:1}
version=${version:1}
fi
# Setting up the environment variables
@ -40,46 +37,24 @@ echo "PROCEED=false" >> $GITHUB_ENV
# Proceed only if the retrieved version is greater than the current one
if ! dpkg --compare-versions "$current_version" "lt" "$version" ; then
echo "::warning ::No new version available"
exit 0
echo "::warning ::No new version available"
exit 0
# Proceed only if a PR for this new version does not already exist
elif git ls-remote -q --exit-code --heads https://github.com/$GITHUB_REPOSITORY.git ci-auto-update-v$version ; then
echo "::warning ::A branch already exists for this update"
exit 0
echo "::warning ::A branch already exists for this update"
exit 0
fi
# Each release can hold multiple assets (e.g. binaries for different architectures, source code, etc.)
echo "${#assets[@]} available asset(s)"
#=================================================
# UPDATE SOURCE FILES
#=================================================
# Here we use the $assets variable to get the resources published in the upstream release.
# Here is an example for Grav, it has to be adapted in accordance with how the upstream releases look like.
# Let's loop over the array of assets URLs
for asset_url in ${assets[@]}; do
# Let's download source tarball
asset_url=$assets
echo "Handling asset at $asset_url"
# Assign the asset to a source file in conf/ directory
# Here we base the source file name upon a unique keyword in the assets url (admin vs. update)
# Leave $src empty to ignore the asset
case $asset_url in
*"admin"*)
src="app"
;;
*"update"*)
src="app-upgrade"
;;
*)
src=""
;;
esac
# If $src is not empty, let's process the asset
if [ ! -z "$src" ]; then
src="app"
# Create the temporary directory
tempdir="$(mktemp -d)"
@ -107,15 +82,10 @@ SOURCE_SUM_PRG=sha256sum
SOURCE_FORMAT=$extension
SOURCE_IN_SUBDIR=true
SOURCE_FILENAME=
SOURCE_EXTRACT=true
EOT
echo "... conf/$src.src updated"
else
echo "... asset ignored"
fi
done
#=================================================
# SPECIFIC UPDATE STEPS
#=================================================

49
.github/workflows/updater.yml vendored Normal file
View file

@ -0,0 +1,49 @@
# This workflow allows GitHub Actions to automagically update your app whenever a new upstream release is detected.
# You need to enable Actions in your repository settings, and fetch this Action from the YunoHost-Apps organization.
# This file should be enough by itself, but feel free to tune it to your needs.
# It calls updater.sh, which is where you should put the app-specific update steps.
name: Check for new upstream releases
on:
# Allow to manually trigger the workflow
workflow_dispatch:
# Run it every day at 6:00 UTC
schedule:
- cron: '0 6 * * *'
jobs:
updater:
runs-on: ubuntu-latest
steps:
- name: Fetch the source code
uses: actions/checkout@v2
with:
token: ${{ secrets.GITHUB_TOKEN }}
- name: Run the updater script
id: run_updater
run: |
# Setting up Git user
git config --global user.name 'yunohost-bot'
git config --global user.email 'yunohost-bot@users.noreply.github.com'
# Run the updater script
/bin/bash .github/workflows/updater.sh
- name: Commit changes
id: commit
if: ${{ env.PROCEED == 'true' }}
run: |
git commit -am "Upgrade to v$VERSION"
- name: Create Pull Request
id: cpr
if: ${{ env.PROCEED == 'true' }}
uses: peter-evans/create-pull-request@v3
with:
token: ${{ secrets.GITHUB_TOKEN }}
commit-message: Update to version ${{ env.VERSION }}
committer: 'yunohost-bot <yunohost-bot@users.noreply.github.com>'
author: 'yunohost-bot <yunohost-bot@users.noreply.github.com>'
signoff: false
base: testing
branch: ci-auto-update-v${{ env.VERSION }}
delete-branch: true
title: 'Upgrade to version ${{ env.VERSION }}'
body: |
Upgrade to v${{ env.VERSION }}
draft: false

View file

@ -5,7 +5,7 @@
#=================================================
# dependencies used by the app
pkg_dependencies="postgresql redis nginx python3-venv libpq-dev php$YNH_DEFAULT_PHP_VERSION"
pkg_dependencies="redis redis-tools redis-server postgresql postgresql-contrib nginx python3-venv libpq-dev php$YNH_DEFAULT_PHP_VERSION"
#=================================================
# PERSONAL HELPERS

View file

@ -64,7 +64,7 @@ ynh_app_setting_set --app=$app --key=admin --value=$admin
ynh_script_progression --message="Finding an available port..." --weight=1
port=$(ynh_find_port --port=8095)
port=$(ynh_find_port --port=8000)
ynh_app_setting_set --app=$app --key=port --value=$port
#=================================================
@ -101,15 +101,10 @@ db_pwd=$(ynh_app_setting_get --app=$app --key=psqlpwd)
#=================================================
ynh_script_progression --message="Setting up source files..." --weight=1
### `ynh_setup_source` is used to install an app from a zip or tar.gz file,
### downloaded from an upstream source, like a git repository.
### `ynh_setup_source` use the file conf/app.src
ynh_app_setting_set --app=$app --key=final_path --value=$final_path
# Download, check integrity, uncompress and patch the source from app.src
ynh_setup_source --dest_dir="$final_path"
chmod 750 "$final_path"
chmod -R o-rwx "$final_path"
chown -R $app:www-data "$final_path"
@ -120,24 +115,14 @@ chown -R $app:www-data "$final_path"
#=================================================
ynh_script_progression --message="Configuring NGINX web server..." --weight=1
### `ynh_add_nginx_config` will use the file conf/nginx.conf
# Create a dedicated NGINX config
ynh_add_nginx_config
#=================================================
# CREATE DATA DIRECTORY
#=================================================
ynh_script_progression --message="Creating a data directory..." --weight=1
### Use these lines if you need to create a directory to store "persistent files" for the application.
### Usually this directory is used to store uploaded files or any file that won't be updated during
### an upgrade and that won't be deleted during app removal unless "--purge" option is used.
### If you're not using these lines:
### - Remove the section "BACKUP THE DATA DIR" in the backup script
### - Remove the section "RESTORE THE DATA DIRECTORY" in the restore script
### - As well as the section "REMOVE DATA DIR" in the remove script
datadir=/home/yunohost.app/$app
ynh_app_setting_set --app=$app --key=datadir --value=$datadir
@ -154,32 +139,13 @@ chown -R $app:www-data "$datadir"
#=================================================
ynh_script_progression --message="Adding a configuration file..." --weight=1
### You can add specific configuration files.
###
### Typically, put your template conf file in ../conf/your_config_file
### The template may contain strings such as __FOO__ or __FOO_BAR__,
### which will automatically be replaced by the values of $foo and $foo_bar
###
### ynh_add_config will also keep track of the config file's checksum,
### which later during upgrade may allow to automatically backup the config file
### if it's found that the file was manually modified
###
### Check the documentation of `ynh_add_config` for more info.
ynh_add_config --template="some_config_file" --destination="$final_path/some_config_file"
# FIXME: this should be handled by the core in the future
# You may need to use chmod 600 instead of 400,
# for example if the app is expected to be able to modify its own config
chmod 400 "$final_path/some_config_file"
chown $app:$app "$final_path/some_config_file"
### For more complex cases where you want to replace stuff using regexes,
### you shoud rely on ynh_replace_string (which is basically a wrapper for sed)
### When doing so, you also need to manually call ynh_store_file_checksum
###
### ynh_replace_string --match_string="match_string" --replace_string="replace_string" --target_file="$final_path/some_config_file"
### ynh_store_file_checksum --file="$final_path/some_config_file"
#=================================================
# SETUP SYSTEMD
@ -200,45 +166,15 @@ ynh_add_systemd_config
#=================================================
ynh_script_progression --message="Integrating service in YunoHost..." --weight=1
### `yunohost service add` integrates a service in YunoHost. It then gets
### displayed in the admin interface and through the others `yunohost service` commands.
### (N.B.: this line only makes sense if the app adds a service to the system!)
### If you're not using these lines:
### - You can remove these files in conf/.
### - Remove the section "REMOVE SERVICE INTEGRATION IN YUNOHOST" in the remove script
### - As well as the section "INTEGRATE SERVICE IN YUNOHOST" in the restore script
### - And the section "INTEGRATE SERVICE IN YUNOHOST" in the upgrade script
yunohost service add $app --description="A short description of the app" --log="/var/log/$app/$app.log"
### Additional options starting with 3.8:
###
### --needs_exposed_ports "$port" a list of ports that needs to be publicly exposed
### which will then be checked by YunoHost's diagnosis system
### (N.B. DO NOT USE THIS is the port is only internal!!!)
###
### --test_status "some command" a custom command to check the status of the service
### (only relevant if 'systemctl status' doesn't do a good job)
###
### --test_conf "some command" some command similar to "nginx -t" that validates the conf of the service
###
### Re-calling 'yunohost service add' during the upgrade script is the right way
### to proceed if you later realize that you need to enable some flags that
### weren't enabled on old installs (be careful it'll override the existing
### service though so you should re-provide all relevant flags when doing so)
#=================================================
# START SYSTEMD SERVICE
#=================================================
ynh_script_progression --message="Starting a systemd service..." --weight=1
### `ynh_systemd_action` is used to start a systemd service for an app.
### Only needed if you have configure a systemd service
### If you're not using these lines:
### - Remove the section "STOP SYSTEMD SERVICE" and "START SYSTEMD SERVICE" in the backup script
### - As well as the section "START SYSTEMD SERVICE" in the restore script
### - As well as the section"STOP SYSTEMD SERVICE" and "START SYSTEMD SERVICE" in the upgrade script
### - And the section "STOP SYSTEMD SERVICE" and "START SYSTEMD SERVICE" in the change_url script
# Start a systemd service
ynh_systemd_action --service_name=$app --action="start" --log_path="/var/log/$app/$app.log"
@ -257,15 +193,9 @@ then
ynh_permission_update --permission="main" --add="visitors"
fi
### N.B. : the following extra permissions only make sense if your app
### does have for example an admin interface or an API.
# Only the admin can access the admin panel of the app (if the app has an admin panel)
ynh_permission_create --permission="admin" --url="/admin" --allowed=$admin
# Everyone can access the API part
# We don't want to display the tile in the SSO so we put --show_tile="false"
# And we don't want the YunoHost admin to be able to remove visitors group to this permission, so we put --protected="true"
ynh_permission_create --permission="api" --url="/api" --allowed="visitors" --show_tile="false" --protected="true"
#=================================================