Skip to content

Feature request: plugin update status + update mutation (parity with Docker container updates) #2012

Description

Context

Third-party clients (mobile/desktop dashboards, monitoring tools) currently can't tell users when an installed Unraid plugin has a newer .plg version available. The only programmatic install path today is installPlugin(input: InstallPluginInput!): PluginInstallOperation!, which requires the caller to already know the URL of a newer release.

Current schema

typePlugin {
name: String!version: String!hasApiModule: BooleanhasCliModule: Boolean
}

No latestVersion, no updateAvailable, no equivalent of the Docker update-status surface.

Existing pattern that works well — Docker

The Docker side already solves this cleanly:

enumUpdateStatus { UP_TO_DATE UPDATE_AVAILABLE REBUILD_READY UNKNOWN }
typeExplicitStatusItem { name: String!updateStatus: UpdateStatus! }
typeDocker { containerUpdateStatuses: [ExplicitStatusItem!]! }
typeDockerMutations {
updateContainer(id: PrefixedID!): DockerContainer!updateAllContainers: [DockerContainer!]!
}

Clients can render a "X updates available" badge and a one-tap update action without scraping registries.

Proposal — mirror for plugins

Either extend Plugin directly:

typePlugin {
 # … existing fieldslatestVersion: StringupdateStatus: UpdateStatus
}

…or add a parallel query field analogous to containerUpdateStatuses:

typeQuery {
pluginUpdateStatuses: [ExplicitStatusItem!]!
}

Plus a mutation, reusing the existing PluginInstallOperation tracking:

typeUnraidPluginsMutations {
updatePlugin(name: String!): PluginInstallOperation!updateAllPlugins: [PluginInstallOperation!]!
}

Why this matters

Plugin updates today require users to visit Community Applications or each plugin's source URL manually. A schema-level surface unlocks "managed-from-anywhere" parity with the Docker experience the API already provides — and the implementation can reuse the existing .plg re-install path (Unraid's webgui already updates by re-running the .plg from the URL it has).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions