Skip to content

Track workflow renames - #1596

Merged
josephjclark merged 16 commits into
release/nextfrom
track-workflow-renames
Oct 22, 2026
Merged

josephjclark merged 16 commits into
release/nextfrom
track-workflow-renames

Conversation

@josephjclark

@josephjclark josephjclark commented Oct 19, 2026 •

Copy link
Copy Markdown
Collaborator

Difficult branch to resolve issue #1594 and replace PR #1587

The basic problem we have is this:

Locally, the CLI uses an id, derived on checkout from a workflow's name, to identify workglows. This id is used as a key in various bits of tracking.

When a workflow name changes in the app, or if a user renames a workflow on the file system, the id changes and a lot of the tracking against that workflow breaks.

Now this can be resolved simply with a fresh checkout, which is what #1587 does. But a deploy shouldn't do a full checkout, and it encourages workflow folders to be deleted, rather than renamed.

What I want is better tracking of workflow identity so that a rename isn't totally distructive.

Here's how we're achieving that.

What this PR basically does is track the UUIDs of each workflow in the checkout.yaml file, and uses UUIDs to match local to remote workflows. When a workflow name changes locally, the id and local paths arent updated - they basically are used as aliases. Users can fix the local paths if they want, or maybe we'll add CLI utils for this. But for now, paths stay the same.

Here's a bit more detail on the changes:

  • Track each workflow's UUID in checkout.yaml
  • Add a util to track workflows where the id may have changed
  • When merging, use UUID as the primary identiifer to track a workflow
  • When deploying, use UUID to track workflows from the local file system against the remote
  • When checking out, use UUIDs to track workflows and avoid removing folders. See CLI: on checkout, warn if mapping a workflow with a changed name #1600

Testing & QA

I've added a whole bunch of integration tests to try and harden testing in this area. I've also restructured the sync tests to try and make them clearer, splitting up by edit verb (rename, edit, remove) rather than command (pull, fetch, deploy)

Here are some suggested manual tests for QA:

  1. Pull a project, rename a workflow in local yaml, deploy
  2. Pull a project, rename a workflow in local yaml, and update step code. The summary says "changed", not "added" or "deleted".
  3. Swap the names of two workflows, deploy → each keeps its own uuid, with the other's old name.
  4. Create notes.md in a workflow folder. Rename a workflow in the Lightning app, then pull with --force. Local workflow name is updated, but folder and file names are unchanged.
  5. Alias a workflow locally. Rename and change remotely. Pull the changes, alias should be preserved.

AI Usage

Please disclose whether you've used AI anywhere in this PR (it's cool, we just
want to know!):

  • I have used Claude Code
  • I have used another model
  • I have not used AI

You can read more details in our
Responsible AI Policy

@github-project-automation github-project-automation Bot moved this to New Issues in Core Oct 19, 2026
@josephjclark
josephjclark changed the base branch from main to release/next October 20, 2026 15:36
@josephjclark
josephjclark marked this pull request as ready for review October 22, 2026 15:44
@josephjclark
josephjclark merged commit 5f265bb into release/next Oct 22, 2026
1 of 2 checks passed
@josephjclark
josephjclark deleted the track-workflow-renames branch October 22, 2026 15:52
@github-project-automation github-project-automation Bot moved this from New Issues to Done in Core Oct 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

2 participants