-
-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add version delimited update list #662
Conversation
7cd8a15
to
c64fe28
Compare
Wow, that looks great! A huge step forward 👍 A few small questions:
|
Absolutely, This can be set up at the start so we'd have three categories,
The same script we used to create the changelogs can be extended to use this right? I've got to figure a way of reading this content into linuxpkg.
.tfr? For transfer? |
So would you allow NOTES/ALERTS also in the PRE and POST categories? If so, what kind of messages should go where?
Yes, but for this we should make sure that we have all content in this file that is required for correctly structuring the changelog (we there e.g. have the addon-id and potentially markdown text) - hence I am not sure how to best fit this in here.
Maybe |
Commands can be processed in any section, but at the moment I only expect them in the [[MSG]] category. I'd guess it would be up to a PR reviewer to see if new additions make sense? At the moment, I'm thinking that NOTES should be used where the user might experience unexpected changes in functionality, whereas an ALERT should be used if the user is required to do something.
NOTES and ALERTS can be set to take only two parameters, so if we define the extra as unused parameters for the update script, they can be still used by the changelog script instead. For example:
The finer details can be thought of after this PR?
|
Sounds like a good definition.
Agreed, e.g. when addressing #668 :-)
Not sure if we need to care too much about that as we do not expect any application associations with this extension. But I am fine with other options as well. Just |
How about Last thing to consider: At the moment, the update script won't action new commands for snapshots. In other words, updating from a 2.3.0 snapshot to a 2.3.0 snapshot won't action any new commands in the I wonder what the best strategy for this would be? Is it better in this case repeat all the latest commands on each snapshot-snapshot update? |
Go for it 👍
I would think so - we should make sure that all those actions are safely repeatable without breaking anything, then they could be executed for every snapshot upgrade (and btw, also for beta and milestone releases). |
How will these versions be specified in |
Yes, that would be the plan! |
All set, upgrades work to 2.3.0-SNAPSHOT from 2.1.0, 2.2.0 and 2.3.0 on Linux. @kaikreuzer, would you be able to test on MacOS? If it helps, my usual test to see if the upgrade completes all steps are:
|
@openhab/docker-maintainers, @openhab/synology-maintainers, @openhab/qnap-maintainers, @bdleedy, @ghys (windows script). Using the change in this PR, would it be possible to complete the update procedure for the relevant system, or is something else required? In summary, the update procedure used by this PR is:
|
Tested, works well! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lgtm, is there anything more you would want to add or wait for or shall we merge?
How can we run this update procedure non interactive? |
If the update can't have input options, then it would probably be best to display the lines on screen or write the messages to an easy to read file?
Not from me, I'll have a look to see how I can integrate this with Linuxpkg. |
Is there an option for the update to go through without interactive input? |
If you are able to directly use the update script, then I can add a non-interactive option into it? |
@kaikreuzer, I am wondering if we should change the use of
to
This way, we can differentiate between needing to move a file, and needing to replace one with a new version. This is probably necessary for Linuxpkg, which detects new versions of the file automatically. |
@BClark09 Not sure if I fully understand the suggestion. What exactly will |
In linuxpkg, apt and rpm packages automatically detect when the maintainer changes a file that is normally a configuration file. |
Meaning, you can do a specific processing of that file for the linuxpkg upgrades? Sure, let's go for that. |
How can I use this process for docker and synology, too? |
Hi @cniweb, sorry for the delay! To bring discussions into a single thread:
Without bringing in dependencies, Windows will have to have separate scripts (AFAIK). However, I have tried to make the You should be able to use the The What do you think? |
I think that's a good way. Both platforms can handle the appropriate environment variables. The dependent packages (like |
b3d676d
to
ca06969
Compare
- Added non-interactive mode Signed-off-by: Ben Clark <ben@benjyc.uk>
ca06969
to
b43874a
Compare
@cniweb, I've added a check for a @kaikreuzer, would you be able to do one more review/test? I made a git error and had to rebase, I believe all the changes are still intact though. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm - didn't do another test, but I am sure we will notice it soon, if it is broken ;-)
Addresses the Linux and Mac OS part of #501
Signed-off-by: Ben Clark ben@benjyc.uk