#10360 feat: show when a plugin has an update from Meltano Cloud Pull request opened by ReubenFrankel Description A user who is logged in to Meltano Cloud cannot tell from the CLI that a plugin in their project is behind the definition that Meltano Cloud serves. This has been true since the CLI started to read the Meltano Cloud Hub on login (#10335).

meltano plugin list

now marks such a plugin with

↑ available

, and the commands that run a plugin, such as

meltano invoke

and

meltano run

, log a warning that names the command to update it. The check sorts every list and then compares the whole lock file with the served definition. A new order is not an update. A new label, description or logo is. Both sides go through the code that writes a lock file, so a value that Meltano fills in, such as a default label, cannot cause a false update. Each served definition is cached for an hour beside the Hub index, so a check makes at most 1 request for each plugin, plus 1 for each plugin type, in an hour. •

PluginLockService.has_update

returns whether an update is available, and

PluginLockService.checks_updates

whether the check runs at all.

has_update

returns

false

for a plugin that it does not check: a custom or inheriting plugin, a plugin that Meltano Cloud does not serve or cannot return, and every plugin when the user is logged out or the project sets its own Hub. •

MeltanoHubService.find_definition

takes

refresh=False

to reuse a cached index and definition, and logs that kind of fetch at

debug

. •

MeltanoHubService.cloud_credentials

is now public, so the check can test for a login without building the Hub service, which prints the login hint. •

meltano plugin list

adds an

UPDATE

column whenever the check runs, a hint under the table when a plugin has an update, and the JSON key

update

. •

invoker_factory

logs the warning. • The

meltano plugin list

reference describes the column and the JSON key. Against Meltano Cloud,

tap-salesforce

(a new

pip_url

tag) and

target-postgres

(new settings and capabilities) show an update. The mapper, which Meltano Cloud does not serve, is not checked. A second run within the hour makes no request. The affected test suites show no new failures. Behaviour changes • For a logged-in user,

meltano plugin list

and each command that runs a plugin make up to 1 Hub request for each plugin, plus 1 for each plugin type, in an hour. A Hub that cannot be reached does not stop the command. The Hub session has no request timeout, so a Hub that hangs also hangs the command, at most once an hour. • The JSON output of

meltano plugin list

has 1 new key,

update

, which is

true

or

false

. The existing

pip_url

key moves to the end of each entry. • A change to a definition that only affects presentation, such as a new logo, shows as an update. Running

meltano add

clears it. • The suggested

meltano add [--plugin-type <type>] <name>

replaces a

pip_url

that a user pinned in

meltano.yml

. Checklist • I have read the contribution guide Was generative AI tooling used to co-author this PR? • Yes (please specify the tool below) Generated-by: Claude Code following the agentic coding guidelines Related Issues • None Summary by Sourcery Surface available Meltano Cloud plugin definition updates in plugin listings and plugin execution warnings. New Features: • Show when a logged-in user’s plugin definition is outdated compared with Meltano Cloud. • Warn when running a plugin with an available Meltano Cloud update. Enhancements: • Compare normalized plugin definitions while ignoring list ordering and exclude custom, inherited, unsupported, and logged-out plugins from update checks. • Reuse cached Hub definitions for up to an hour and treat Hub availability failures as non-blocking. Documentation: • Document the plugin update indicator, JSON output field, comparison behavior, caching, and update command. Tests: • Add coverage for update detection, caching behavior, CLI output, and runtime warnings. --- 🤖 Generated with Claude Code meltano/meltano