Skip to content

feat: cycle create, update, and archive commands#111

Draft
lightstrike wants to merge 2 commits intoflipbit03:mainfrom
lightstrikelabs:feat/cycles-crud
Draft

feat: cycle create, update, and archive commands#111
lightstrike wants to merge 2 commits intoflipbit03:mainfrom
lightstrikelabs:feat/cycles-crud

Conversation

@lightstrike
Copy link
Contributor

Summary

  • Add cycles create, cycles update, and cycles archive CLI subcommands
  • Generate cycleCreate, cycleUpdate, cycleArchive SDK mutations via codegen
  • Include offline tests (help output, validation) and online tests (full CRUD lifecycle)

Test plan

  • cargo build --workspace compiles
  • cargo clippy --workspace -- -D warnings clean
  • cargo fmt --check passes
  • Offline tests pass (4 new)
  • SDK online tests pass (cycle_create_update_and_archive)
  • CLI online tests pass (cycles_create_update_and_archive)

Note: Online tests depend on #105 (configurable test team env var) for reliable execution against workspaces where the first team alphabetically is non-functional.

@flipbit03
Copy link
Owner

Hey @lightstrike — thanks for your enthusiasm and all these contributions! We just released v2.0.0 which includes several of your earlier contributions — great work!

Quick heads-up on workflow: with multiple draft PRs open at once, they tend to go stale fast as main moves forward and earlier PRs get merged (causing conflicts in later ones). Looking at our recent merged PRs (#88, #91, #92, #106, #107, #108, #112), I had to push 30+ commits across your branches — merge conflict resolution, rebasing on main, reworking implementations, fixing tests, updating docs — on top of your original work. I'm happy we got all of that shipped together, but that level of serial branch maintenance isn't sustainable on my end going forward.

To keep things smooth, it'd be great if you could pick the one you'd like to land first, rebase it on the latest main, and mark it as ready for review. Once that's merged, move on to the next one, and so on. That way each PR is up to date and reviewable, and we avoid a pile-up of conflicts.

Also, going forward — for PRs that involve design or architectural changes, please open an issue first so we can discuss the approach before code is written. That way we align on direction early and avoid wasted effort on both sides. (See #115#126#127 as an example of how that played out.)

Tag me (@flipbit03) when it's ready for review. Looking forward to it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants