renku
renku copied to clipboard
SwissDataScienceCenter
Project Template Updating
Description
Users should be notified if there is an applicable new version of the project template used to create the project.
Details
When a project template is updated, it means that there is an improved version available. Users should be notified of this and be given the option to upgrade or ignore. We probably want to handle new minor versions and new major versions differently.
This needs a lot more detail - we should have a design discussion around this topic soon.
@ciyer @Panaetius this doesn't include any issues about how to actually do the update of the template - is the behavior still that it overwrites the user's changes?
I guess this isn't documented anywhere, so I'll write it here :sweat_smile: It never overwrote the users changes. It only updates files that the user didn't change. But it allows a template to specify files that a user isn't allowed to change, and if they changed it anyways, then it won't perform/allow an update as the project is considered in an invalid state from the view of the template. It does a three-way compare of original version, current version in template and current version in the project.
What I think this epic actually lacks is defining a proper design for template versions and how to handle them. Currently, if there is a newer commit in the template repo than the one used in the project, it says that this can be updated. Which works and solves the problem, but is a bit too low-level and simplistic for what we want in the future, I think. We don't have a version in the manifest (What should that look like, just major.minor? And what implications would a change in major or minor version have in regards to the update), we don't have a way to do a changelog and we don't have a way to diff that changelog to e.g. get all changes between version 1.3 and 4.7 and show them to the user. But it should be able to do this on top of the current implementation (it was done with something like this in mind). Or let's say I edit some file in the template but forget to update the version in the manifest. Now we wouldn't trigger an update for old projects, but new projects would get the modified file, and suddenly you have projects that all say they used version 1.3, but have differing files. And now we remember and do update the manifest to 1.4, the former projects will get the new file as part of the update, but the newer projects will see "oh there's an update, but... nothing changed?!?".
We would need to specify it and decide who is in charge of maintaining this. We discussed something like this at some point, but never followed up on it. On the rp side this mainly is because, while renku-python is the thing that updates the projects, it cares very little about the templates and their content and they are mainly useful for others (setting up the environment, docker/gitlab builds, dev environment etc.) and I didn't want to impose a renku-python view on how the templates should be structured in regards to this, as we likely won't be the ones maintaining them.
On a side note, whatever ref was used in the template repo is what is used to check for changes. So using a tag in the template repo means it never gets updated, as there can never be a new commit on the tag.
