Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
#2,012 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
45/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
graphql, typescript

調査の方向性

Start by tracing the existing installPlugin mutation, Plugin schema, PluginInstallOperation, and Docker update-status and update mutation patterns. Review how the webgui re-runs a plugin's .plg URL, then determine the needed schema and resolver entry points. Done means clients can read plugin update status and invoke individual or all-plugin updates with operation tracking comparable to Docker.

索引モデルが issue の本文から書いたものです。

説明

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
type Plugin {
    name: String!
    version: String!
    hasApiModule: Boolean
    hasCliModule: 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:

enum UpdateStatus { UP_TO_DATE  UPDATE_AVAILABLE  REBUILD_READY  UNKNOWN }
type ExplicitStatusItem { name: String!  updateStatus: UpdateStatus! }
type Docker { containerUpdateStatuses: [ExplicitStatusItem!]! }
type DockerMutations {
    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:

type Plugin {
    # … existing fields
    latestVersion: String
    updateStatus: UpdateStatus
}

…or add a parallel query field analogous to containerUpdateStatuses:

type Query {
    pluginUpdateStatuses: [ExplicitStatusItem!]!
}

Plus a mutation, reusing the existing PluginInstallOperation tracking:

type UnraidPluginsMutations {
    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).

主要言語
TypeScript
スター
113
フォーク
22
平均マージ
10時間 40分
マージ済み PR(30日)
13

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

unraid/api のほかの issue

unraid/api の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。