cub changeorder refresh-stage

Work out the stage of a change order, or of multiple change orders, again

Synopsis

Work out the stage of a change order again, from the releases, live status, attestations and validation results it depends on.

The stage a change order has reached in its ChangeWorkflow is stored, and is worked out again when the change order is promoted or updated, when a release is published for it or its live status is reported, and when an attestation is recorded in a space it is headed for. Refresh it when what it depends on changed some other way: a unit validated again, or a space taking the change by "cub unit update --upgrade" or a link resolving rather than by "cub variant promote".

Refreshing requires Use permission on the change order, not the Edit permission an update does.

Examples:

  # Refresh one change order
  cub changeorder refresh-stage --space my-base release-42

  # Refresh every change order of a space that has not completed its workflow
  cub changeorder refresh-stage --space my-base --where "Stage != 'Completed'"

  # Refresh specific change orders by slug
  cub changeorder refresh-stage --space my-base --changeorder release-42,release-43

cub changeorder refresh-stage [<slug or id>] [flags]

Options

      --changeorder strings           target specific changeorders by slug or UUID (can be repeated or comma-separated)
      --dry-run                       report what the command would write, and write nothing
      --filter string                 Filter entity to apply to the list. Specify as 'space/filter' for cross-space filters or just 'filter' for current space. Supports both slugs and UUIDs. The filter will be combined with any --where clause using AND logic. Examples: "production-filters/security-check", "my-filter-uuid", "validation-rules"
  -h, --help                          help for refresh-stage
      --include-hidden string[="*"]   Also select hidden entities, to list or to act on: those hidden for the given HiddenReasons, comma-separated, as in --include-hidden=BackingUnit, or for any reason when given no value or "*". ConfigHub/YAML Units, which hold the configuration of other entities, are hidden with the reason BackingUnit. A --where naming entities by Slug or ID selects them whether hidden or not
  -o, --output string                 Output format. One of: json, yaml, name, wide, mutations, jq=<expr>, yq=<expr>, custom-columns=<spec>
      --quiet                         No default output.
      --verbose                       Detailed output, additive with default output
      --where string                  Filter expression using SQL-inspired syntax. Supports conjunctions with AND. String operators: =, !=, <, >, <=, >=, LIKE, NOT LIKE, ILIKE, ~~, !~~, ~, ~*, !~, !~*. Pattern matching with LIKE/ILIKE uses % and _ wildcards. Regex operators (~, ~*, !~, !~*) support POSIX regular expressions. A related entity is referenced by prefix, as in "UpstreamUnit.Slug = 'base'"; when the reference names a list, a * segment matches any element, as in "FromLink.*.Slug = 'upgrade-app'". Examples: "Slug LIKE 'app-%'", "DisplayName ILIKE '%backend%'", "Slug ~ '^[a-z]+-[0-9]+$'". 'cub <entity> explain --where' lists the attributes an entity's expressions can name

Options inherited from parent commands

      --component string   the Component of --variant, when that names the variant alone; --variant <component>/<variant> says the same in one flag
      --context string     The context to use for this command
      --debug              Debug output
      --space string       space to operate in, by slug or UUID. Omitted, a list or bulk operation spans the organization and a single entity is named as <space>/<slug>; "*" means the same as omitting it
      --variant string     variant to operate in, as <component>/<variant>, or as <variant> with --component: the space naming that Component whose Variant label is <variant>. The same scope as --space, named by what it is rather than by the space's slug; the two cannot be combined

cub changeorder refresh-stage