console-helpers / svn-buddy-updater

GitHub Actions App for updating SVN-Buddy

SVN-Buddy Updater

This is a code of GitHub Actions App, that keeps SVN-Buddy up to date.

License

SVN-Buddy Updater is released under the BSD-3-Clause License. See the bundled LICENSE file for details.

svn-buddy-updater's Issues

Added "/download/latest/" url

Added /download/latest/ url to download latest release:

• when stability GET parameter omitted it's considered as stable

Will automatically download svn-buddy.phar that /versions url will return for that stability.

Change update storage logic

Before:

1. URLs for downloading GitHub Releases (from GitHub) and snapshot/preview releases (from Amazon S3) are stored in the Postgress database on Heroku
2. the SVN-Buddy is accessing http://svn-buddy-updater.herokuapp.com/versions URL and from these discover if there is a new version or not

After:

1. store the releases table from the Postgres database as a releases.json file in the SVN-Buddy-Updater repository on GitHub
2. instead of performing database queries change the releases.json file
3. when changing a releases.json file, then make sure you commit it back to the repo
4. SVN-Buddy will download the releases.json file and see for itself what needs to be done
5. setup a GitHub action, that daily at 1:00 AM the bin/svn-buddy-updater snapshot:create command is executed (how to set up: https://docs.getnacelle.com/deployment/scheduled-builds-github-actions.html#add-the-webhook-url )

Separate "sync" command into two

Right now sync command does 2 things (depending on given option):

• sync releases from GitHub
• create snapshot release at the end of a week

Need to separate them into 2 commands:

• release:sync
• snapshot:create

As a bonus add --force option to snapshot:create command and when specified create snapshot release from HEAD commit instead of taking last commit from past week.

Add "s3:logs" command

Since snapshot/preview releases are downloaded from s3 bucket directly it doesn't make sense to have application-level download log. Instead I've enabled S3 logs.

Need to add "s3:logs" command that would:

1. download & show logs
2. rotate them so that they don't take too much space in the bucket
3. for historical purposes track downloads of each version in separate table that would exist even after release is deleted

Change version comparison to understand manually built phars

Right now it's considered that there is new version available, when:

• for snapshot/preview releases if PHAR's SHA is different from local PHAR's SHA
• for stable releases if local phar version is smaller compared to latest stable version in GitHub

This doesn't work well for:

• PHAR's built manually (not available as version)
• PHAR's of non-stable releases

because their version looks like snapshot:v0.2.0-43-g181a34d.

To solve this a new update strategy needs to be created that will:

For snapshot/preview releases

1. strip namespace off the version (e.g. snapshot: or preview: or stable:)
2. explode by - what's left
3. compare versions and
   • if 2nd is larger then it's an update for sure
   • if 2nd is smaller then it's not an update for sure
4. if both versions match compare number between - (the 43 in above example); if either of version don't have this number use 0 for comparison
5. the version with larger number is considered to be an update

For stable releases

1. provide main version part (the v0.2.0 in above example) to the GitHubStrategy