Allow for easier version updates on an existing project

[apolopena]

Problem this feature will solve

As it stands a project built on this project will use the files from this project but with no real ties to the repository itself. As a result of this, any project built on this project can break if Gitpod changes something (like a major version of php or mysql) in their workspace-full, base or mysql image.

Users needs an easier way to update gitpod-laravel-starter such as via a script.

Background

This project is built on Gitpods https://github.com/gitpod-io/workspace-images/tree/master/mysql This project has intnetionally not pinned down the workspace image so that users can benefit for the updates that Gitpod provides however this can also break a users project.

Allowing a user to pin just their their Gitpod workspace image version would be amazing but technically I do not think that it is possible to do dynamically. A user could do this on thier own if they new what they were doing.

Proposed Solution

Create a system that will update the gitpod-laravel-starter to the latest version or possibly even allow a user to swap to whatever version of gitpod-laravel-starter they like.

As a first attempt at writing this system we can make of three files:

• manifest.sh
  • autogenerates .gls-manifest
• .gls-manifest (autogenerated and .gitignored)
  • A list of all the files that should (and should not) be deleted when update-core.sh is run.
• update-core.sh
  • Performs the update as per .gls-manifest

Constraints and Assumptions

<! -- Any constraints and/or assumption relevant for the development and use of this feature? --> Some core files will most likely be edited by the user and those files should be omitted when the gitpod-laravel-starter version is updated/swapped.

Technically the user should only be changing the files that were designed to be changed by the user which are init-project.sh and install-project-packages.sh and whatever 'user editable' files this project will provide in the future.

If a user was given the ability to omit certain files from the update then the project could easily break. However if the user knows what they are doing they will be able to merge their changes into the updated files and everything will be fine.

Warn the user that they may need to merge changes at their own risk if they have changed any of the gitpod-laravel-starter core files such as .gitpod.yml and .gitpod.Dockerfile

Alternatives or Workarounds

Make the version update/swap manually by deleting the existing gitpod-laravel-starter files and then replacing them with new files for the repository.

Additional context

Add any other context or screenshots about the feature request here.

[apolopena]

Update the proposed solution use use diff in a bash script that is curled and ran interactively.

1. Download the tarball release and untar it
2. Run diff something like this: diff -qr --exclude=.git gitpod-laravel-starter gitpod-laravel-starter-1.4.0

All though there will be other project files in the project root besides the gls (gitpod-laravel-starter) files so there may need to be a selective copy to isolate the existing gls files in order to compare them with the gls release.

[apolopena]

First step of the update probably will be getting the latest release and logging the changed files.

One appraoch to this first step could be to create a working directory for the update/comparison by downloading the latest release into via wget, untar it and then make the file comparison using rsync. Next steps and user prompts would be based off which files were changed. In a perfect world only starter.ini, .gp/bash/init-project.sh would be changed. Currently packages the user wants downloaded during the image build step are in .gp/bash/install-project-packages.sh but that string should really be parsed from starter.ini so .gp/bash/install-project-packages.sh can remain untouched.

So something like this: (note when testing the update locally on a windows WSL system include the --no-hsts option to suppress the hsts warnings`

gls_latest_ver="1.4.0"
gls_url="https://github.com/apolopena/gitpod-laravel-starter/archive/refs/tags/v$gls_latest_ver.tar.gz"
gls_tar="${gls_url##*/}"
tmp_d="tmp_update_gls"

mkdir -p "$tmp_d"
cd "$tmp_d"
wget "$gls_url" -no--verbose
tar -xvzf "$gls_tar" && rm "$gls_tar"
rsync -naic ../ "gitpod-laravel-starter-$gls_latest_ver/"

[strausmann]

Can't wait for when the update process gets easier.... Thanks for this feature :-)

[apolopena]

This is the work in progress: https://github.com/apolopena/gls-tools/

• The idea is for future releases a bash script in the bin folder will facilitate the curl-ing and execution of the updater script from its repo.
• old versions of gitpod-laravel-starter will need the user to manually install and execute the script
• The updater script will be interactive. I would also like to have a --force option that forces the update with no interactivity.
• The script will be graceful, if it fails it wont leave a half done mess around.

[strausmann]

What do you think about adding an install option to the update script?

Example, you have developed a Laravel project so far completely without GitPod. You used the standard Laravel directory structure.

Now you download your script, it detects that the .gp folder and the other files are not present and completely loads the Laravel Starter into the existing Laravel structure.

Just as an idea...

[strausmann]

Can you do anything with it? I can help you with more information?

[strausmann]

Saw that the header line "[delete]" was still missing in the manifest. After that the script also ran a bit further.

So for the default manifest display, the header "[delete]" should be displayed too :-)

Except for this directory and the content, however, nothing else happened after the update.

[apolopena]

What do you think about adding an install option to the update script?

Example, you have developed a Laravel project so far completely without GitPod. You used the standard Laravel directory structure.

Now you download your script, it detects that the .gp folder and the other files are not present and completely loads the Laravel Starter into the existing Laravel structure.

Just as an idea...

I like it, I put it on the map, thanks. https://github.com/apolopena/gls-updater/issues/1

@strausmann The pre-release version of install.sh works now but will overwrite any existing files in your project that are on this list. Consider this a 'nightly' version for now. Unstable but working at the moment.

bash <( curl -fsSL https://raw.githubusercontent.com/apolopena/gls-tools/main/tools/install.sh )

[apolopena]

@strausmann Yeah the script is not functional yet. I still need to do quite a few things:

• [x] finish and test the directive routines
  • [x] Finish the recommend_backup routine for files (directories works)
  • [x] Make the mapping for recommended backups better (currently its just a 1 to 1 file in the root the backup folder).
  • [x] ~~Create the delete directive~~
  • [x] get rid of the merge directive for now (https://github.com/apolopena/gls-updater/blob/main/local-merge.sh) in favor of a user initiated manual merge after the update since I have not been able to git merge-file to give me more than one conflict marker per file, see here.
• [ ] Dial in the .updater-manifest and the default manifest better
• [x] Perform the copying of the latest version of gitpod-laravel-starter once the versions checks, setup, download and directives, have succeeded. Keep in mind kept files.
• [ ] Abort if a directive fails
• [ ] Abort if the rsync fails
• [ ] Cleanup properly after any abort or on full success
• [ ] Eventually add an update.log
• [x] Eventually add a --force option or make it so the script can be ran with yes
• [x] Eventually add an install option

[apolopena]

Getter closer! Not yet ready for release though. https://github.com/apolopena/gls-tools