Mix and match update types?

Development
1

I currently have my plugin configured using the github_release update strategy and this is great for my master and release candidate branches.

type='github_release',
            user='synman',
            repo='OctoPrint-Bettergrblsupport',
            current=self._plugin_version,
            stable_branch={
                    "name": "Stable",
                    "branch": "master",
                    "commitish": ["master"],
                },
            prerelease_branches=[
                    {
                        "name": "Release Candidate",
                        "branch": "rc",
                        "commitish": ["rc", "master"],
                    },
                    {
                        "name": "Development",
                        "branch": "devel",
                        "commitish": ["devel", "rc", "master"],
                    }
                ],
            pip='https://github.com/synman/OctoPrint-Bettergrblsupport/archive/{target_version}.zip'))

Is there a way to define multiple strategies? For example, I would really like to keep my master and rc branches release/tag based, but offer a devel branch strategy based on commit (github_commit).

2

Is this the right place to ask this question? I don't want to unnecessarily clutter up the github issues list.

3

Yes, there's just limited number of people that would know this answer directly without digging through the code I suspect (ie Gina who is on vacation right now). You could also jump in Discord and ask in #dev-plugins channel...

4

From what I can tell you can only use one or the other. I'm sure it's possible to hack around that but not sure how much would be involved.

5

You can add more than one update check to the highest level dict there, it just needs a different key - probably prefix it with your plugin id.

Something like:

return {
            "ws281x_led_status": {
                "displayName": "WS281x LED Status",
                "displayVersion": self._plugin_version,
                # version check: github repository
                "type": "github_release",
                "user": "cp2004",
                "repo": "OctoPrint-WS281x_LED_Status",
                [......]
            },
            "ws281x_led_status_2": {
                ... Second configuration
                "type": "github_commit",
            }
        }

However both would be used at the same time, which is probably not recommended... So I would add my own setting in the plugin's UI to change it, and then conditionally return two different update configurations depending on which the user has chosen.

Also, I second the recommendation to join the discord server, we have more regular development conversations there as it's easier to go back and forth.

6

Ok, this is very cool, will require some.thinking, and follow up questions I'll ask via discord

7

thanks again for all the help...

here's how I solved this:

    # #~~ Softwareupdate hook
    def get_update_information(self):
        # Define the configuration for your plugin to use with the Software Update
        # Plugin here. See https://github.com/foosel/OctoPrint/wiki/Plugin:-Software-Update
        # for details.

        useDevChannel = self._settings.get_boolean(["useDevChannel"])

        if useDevChannel:
            return dict(bettergrblsupport=dict(  # version check: github repository
                                                 # update method: pip
                displayName='Better Grbl Support (Development Branch)',
                type='github_commit',
                user='synman',
                repo='OctoPrint-Bettergrblsupport',
                branch="devel",
                current="fd0b1bac7a23ba4b01f58353c7a19c6bc4ea219e",
                method="pip",
                pip='https://github.com/synman/Octoprint-Bettergrblsupport/archive/refs/heads/devel.zip'))

        else:
            return dict(bettergrblsupport=dict(  # version check: github repository
                                                 # update method: pip
                displayName='Better Grbl Support',
                displayVersion=self._plugin_version,
                type='github_release',
                user='synman',
                repo='OctoPrint-Bettergrblsupport',
                current=self._plugin_version,
                stable_branch={
                        "name": "Stable",
                        "branch": "master",
                        "commitish": ["master"],
                    },
                prerelease_branches=[
                        {
                            "name": "Release Candidate",
                            "branch": "rc",
                            "commitish": ["rc", "master"],
                        },
                        {
                            "name": "Development",
                            "branch": "devel",
                            "commitish": ["devel", "rc", "master"],
                        }
                    ],
                pip='https://github.com/synman/OctoPrint-Bettergrblsupport/archive/{target_version}.zip'))
2 Likes
8

may have found a bug while using this as part of every day practice. I quickly discovered I had to update the plugin's version # in setup.py as part of my commits or octoprint / pip would think there was no version change when it triggered off a new commit.

Was reallly annoying, but with some help, I figured out an alternative....

    if useDevChannel:
        checkout_folder = os.path.dirname(os.path.realpath(sys.executable))
        return dict(bettergrblsupport=dict(  # version check: github repository
                                             # update method: pip
            displayName='Better Grbl Support (Development Branch)',
            type='github_commit',
            user='synman',
            repo='OctoPrint-Bettergrblsupport',
            branch="devel",
            method="update_script",
            update_script="{python} -m pip --disable-pip-version-check install https://github.com/synman/Octoprint-Bettergrblsupport/archive/refs/heads/devel.zip --ignore-installed --force-reinstall --no-deps --no-cache-dir",
            checkout_folder=checkout_folder))
    else:
    ...
1 Like
9

relevant ticket. GitHub tags are only read up to the first `-` character, breaking tags such as `1.0.0-rc1` · Issue #4362 · OctoPrint/OctoPrint · GitHub

10

Looks like a bug if the Commit-Trigger is blocked by the version number? Perhaps the PIP call can be changed in OctoPrint if git_commit is used...did you created an issue (or feature request) for this?

I implemented it the same way now, thanks for the preparation. :slight_smile:

11

I think they are separate issues. I'll follow up on the issue referenced.

12
13

Some remarks based on my own plugin:

  • You should delete --ignore_installed -> installed packages will not be uninstalled so there could be artefacts of your plugin left (but not critical in my opinion)
  • Depends on your plugin: you can add parameter restart: "octoprint" to your configuration. Then Octoprint forces a restart automatically. That is the behaviour with standard PIP. You can also request a restart from the whole system if necessary. Found that parameter during debugging it is not documented in the Wiki pages I know.
1 Like
14

reference

That's interesting, didn't know you could do that. RestartNeeding or Template mixins will automatically trigger a restart though IIRC. This way just does it without the prompt in the UI?

15

That is the procedure to determine the restart behaviour. Only in PIP mode the restart is requested by default. In script mode (and others) you have to set it manually and then it have the same behaviour like before. But if restart is not needed it is a nice way to avoid it.

grafik
grafik1234×530 63.4 KB

16

And here I thought I found a feature with the update_script method. I've been kinda digging the no auto restart as it gives me a chance to review the update window.

But yeah... this is going to grow old quick enough. I've already found myself having to click around the PNotify "Update success..." message to get to the restart option in the navbar.