feat-registry-github-actions-trigger-migration

[toyamarinyon]

No description provided.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
giselle	Ready	Preview	Comment	Nov 6, 2025 10:24am
ui	Ready	Preview	Comment	Nov 6, 2025 10:24am

[changeset-bot]

⚠️ No Changeset found

Latest commit: 84343b0

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

💥 An error occurred when fetching the changed packages and changesets in this PR

Some errors occurred when validating the changesets config:
The package or glob expression "giselles-ai" is specified in the `ignore` option but it is not found in the project. You may have misspelled the package name or provided an invalid glob expression. Note that glob expressions must be defined according to https://www.npmjs.com/package/micromatch.

[giselles-ai]

Finished running flow.

Step 1
🟢	On Pull Request Opened Status: Success Updated: Nov 6, 2025 7:05am
Step 2
🟢	Manual QA Status: Success Updated: Nov 6, 2025 7:09am
🟢	Prompt for AI Agents Status: Success Updated: Nov 6, 2025 7:09am
Step 3
🟢	Create a Comment for PR Status: Success Updated: Nov 6, 2025 7:12am
Step 4
🟢	Create Pull Request Comment Status: Success Updated: Nov 6, 2025 7:12am

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch feat-registry-github-actions-trigger-migration

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[giselles-ai]

## 🔍 QA Testing Assistant by Giselle

### 📋 Manual QA Checklist

Based on the changes in this PR, here are the key areas to test manually:

• Workflow Editor: GitHub Trigger Configuration: Create a new GitHub Trigger node, configure it for "Issue Comment Created" with a callsign and repository, and verify the node's state and output ports.
• Workflow Editor: GitHub Trigger Execution: Enable the configured GitHub Trigger and test by posting a comment on GitHub that matches the trigger's criteria. Verify a new run is created on the application's "Runs" page.
• Workflow Editor: GitHub Action Configuration: Add a GitHub Action node, configure it for "Create Issue", and verify its input ports.
• Workflow Editor: Connected GitHub Trigger and Action: Connect the output of the GitHub Trigger node to the inputs of the GitHub Action node. Trigger the workflow via GitHub and verify the action executes and creates an issue with the correct content.
• Workflow Editor: Reconfiguration of GitHub Trigger: Reconfigure an existing GitHub Trigger to a different event type (e.g., "Issue Labeled"), verify updated output ports, and test triggering with the new event.
• Manual Trigger Configuration and Stage Execution: Create a workflow with a Manual Trigger, add parameters, stage the workflow, and verify that the parameters are correctly presented on the "Stage" page and that the workflow runs successfully with provided inputs.
• Agent/Workspace Copying: Copy an Agent/Workspace containing a configured GitHub workflow, verify the copied workflow retains its configuration, enable the trigger in the copied agent, and confirm only the copied agent's workflow is triggered by GitHub events.

### ✨ Prompt for AI Agents

Use the following prompts with Cursor or Claude Code to automate E2E testing:

📝 E2E Test Generation Prompt

```

You are an expert QA engineer specializing in automated E2E testing with Playwright. Your task is to generate a comprehensive E2E test suite for the provided pull request. The PR involves a major refactoring of how triggers and actions, particularly for GitHub, are defined and managed within the application.

1. Context Summary

PR Changes

This pull request executes a significant architectural refactoring. It removes the monolithic @giselles-ai/flow package and introduces two new, more focused packages: @giselles-ai/action-registry and @giselles-ai/trigger-registry.

The core change is a migration of all code that previously relied on flow to use these new registries. This includes a widespread renaming of data structures and functions:

• FlowTrigger is now Trigger.
• flowTriggerId is now triggerId.
• Functions like useFlowTrigger, flowTriggerUpdate, and getFlowTrigger have been renamed to useTrigger, triggerUpdate, and getTrigger respectively.

Key User Flows Affected

The user flows for creating and configuring workflows that interact with external services are heavily impacted. Specifically:

• Adding and configuring GitHub Trigger nodes on the workflow canvas.
• Adding and configuring GitHub Action nodes on the workflow canvas.
• Running workflows with these nodes from the "Stage" area.
• Copying a workspace that contains configured GitHub triggers.

Critical Paths to Test

1. GitHub Trigger Configuration: The entire lifecycle of adding a GitHub trigger, selecting the event type (e.g., "Issue Comment Created"), choosing a repository, setting conditions (like callsigns or labels), and seeing the updated state on the canvas and in the properties panel.
2. GitHub Action Configuration: The process of adding a GitHub action, selecting the action type (e.g., "Create Issue"), and mapping inputs from other nodes.
3. End-to-End Workflow Execution: A simple workflow (e.g., GitHub Trigger -> GitHub Action) should be tested via the "Stage" page to ensure the new registry-based definitions are correctly executed by the backend engine.
4. Regression on Manual Triggers: Ensure that non-GitHub triggers, like the "Manual" trigger, have not been broken by this refactoring.

2. Test Scenarios

Create E2E tests covering the following scenarios. Organize them into logical test files (e.g., github-trigger.spec.ts, github-action.spec.ts).

github-trigger.spec.ts

• Test: Successfully add and configure a new GitHub Trigger.

  • Steps:
    1. Navigate to a new workspace.
    2. Open the "Add Node" toolbar.
    3. Select the "Trigger" tool and then "GitHub".
    4. Click on the canvas to add a "GitHub Trigger" node.
    5. Select the new node to open its properties panel.
    6. In the properties panel, select an event type, e.g., "Issue Comment Created".
    7. Select a mock repository.
    8. Enter a callsign (e.g., @giselle).
    9. Click "Create Trigger".
  • Assertions:
    • The node on the canvas should update its name to "On Issue Comment Created".
    • A badge with the selected repository name should appear on the node.
    • The properties panel should now show the configured view with an "Enabled/Disabled" toggle.
    • The correct event type and repository should be displayed in the configured view.

• Test: Reconfigure an existing GitHub Trigger.

  • Steps:
    1. Start with a configured "Issue Comment Created" trigger.
    2. In the properties panel, click "Reconfigure".
    3. Change the repository.
    4. Click the "Update Trigger" button.
  • Assertions:
    • The repository badge on the node should update to the new repository name.
    • The properties panel should reflect the new repository.

• Test: Enable and disable a GitHub Trigger.

  • Steps:
    1. Start with a configured trigger.
    2. Click the toggle in the properties panel to disable it.
    3. Click the toggle again to re-enable it.
  • Assertions:
    • After each toggle action, verify the UI state of the toggle button itself.
    • (Optional) Mock the backend call (setTrigger) and assert that it's called with enable: false and then enable: true.

github-action.spec.ts

• Test: Successfully add and configure a new GitHub Action.
  • Steps:
    1. Navigate to a new workspace.
    2. Add a "GitHub Action" node from the toolbar.
    3. Select the new node.
    4. In the properties panel, select an action type, e.g., "Create Issue".
  • Assertions:
    • The node name on the canvas should update to "Create Issue".
    • The properties panel should show the configured view for the "Create Issue" action.
    • The node should have the correct inputs ("title", "body").

workspace-github-workflow.spec.ts

• Test: Create and connect a simple GitHub Trigger -> Action workflow.

  • Steps:
    1. Configure a "Manual" trigger with a text parameter named "issue_title".
    2. Configure a "GitHub Action" node for "Create Issue".
    3. Drag a connection from the "issue_title" output of the Manual Trigger to the "title" input of the "Create Issue" action node.
  • Assertions:
    • A connection line should be visible on the canvas between the two nodes.
    • The properties panel for the action node should show the input as connected.

• Test: Run a Manual Trigger from the "Stage" page that fires a GitHub Action.

  • Setup: Create a workspace with a staged "Manual" trigger (with a parameter for "title") connected to a "Create Issue" GitHub action.
  • Steps:
    1. Navigate to the /stage page.
    2. Select the correct team and the staged app from the dropdown.
    3. Fill in the "title" input field with "E2E Test Issue".
    4. Click the "Run" button.
  • Assertions:
    • Assert that the page navigates to an act details page (e.g., /stage/acts/...).
    • Assert that a success notification or status message is displayed.

3. Playwright Implementation Instructions

Mocking API Calls

This refactoring relies on backend interactions. Use page.route() to mock API calls to the Giselle Engine for stability and speed. This is crucial.

```typescript
// Example of mocking the engine's getTrigger call
await page.route('**/api/json/getTrigger', async (route) => {
const mockTrigger = {
// ... complete mock Trigger object
};
await route.fulfill({ json: { trigger: mockTrigger } });
});

// Mock the repository selection
await page.route('**/api/json/getGitHubRepositoryFullname', async (route) => {
await route.fulfill({ json: { fullname: 'test-org/test-repo' } });
});
```

Selectors to Target

• Toolbar:
  • Add Node Tool: page.getByRole('button', { name: 'Add Node' })
  • Action/Trigger Providers: page.getByText('GitHub Action'), page.getByText('GitHub Trigger')
• Properties Panel:
  • Event/Action Selection: Use page.getByRole('button', { name: '...' }) inside the panel. The items are buttons in a list, e.g., page.getByRole('button', { name: 'Issue Comment Created' }).
  • Callsign Input: page.getByPlaceholder('e.g. @giselle')
  • Create/Update Buttons: page.getByRole('button', { name: 'Create Trigger' })
• Canvas:
  • Nodes: page.locator('.react-flow__node').filter({ hasText: 'On Issue Comment Created' })
  • Node Handles for connections: page.locator('[data-handleid="..."]')
• Stage Page:
  • App Selector: page.getByTestId('app-selector') (you may need to add this data-testid).
  • Run Button: page.getByRole('button', { name: 'Run' })

User Interactions

• Navigation: Use page.goto('/workspaces/some-id') and page.goto('/stage').
• Drag and Drop: Use page.dragAndDrop() for creating connections between node handles.
• State Setup: Use a global setup file (global.setup.ts) to programmatically create a user and a workspace, and save the authentication state to a file. Each test file will then use this stored state.

```typescript
// in playwright.config.ts
globalSetup: require.resolve('./tests/e2e/global.setup.ts'),

// in tests
test.use({ storageState: 'storageState.json' });
```

Assertions

• Verify UI text and visibility: await expect(page.getByText('...')).toBeVisible();
• Verify node state via attributes: await expect(nodeLocator).toContainText('On Issue Comment Created');
• Verify backend calls were made (optional, advanced):
  ```typescript
  let triggerPayload;
  await page.route('**/api/json/setTrigger', (route, request) => {
  triggerPayload = request.postDataJSON();
  route.fulfill({ status: 200 });
  });
  // ... perform action ...
  expect(triggerPayload.trigger.enable).toBe(false);
  ```

4. MCP Integration Guidelines (Optional)

The AI Agent does not need to generate these commands, but should be aware of the structure.

• Running tests: `npx playwright test`
• Running a specific file: `npx playwright test tests/e2e/github-trigger.spec.ts`
• Environment Config: Tests should assume a `.env` file is present for database connections and other secrets, loaded by Playwright's config.

5. CI-Ready Code Requirements

• Test Organization:
  • Group related tests using `test.describe('Feature Name', () => { ... });`.
  • Use `test.beforeEach` to navigate to a clean workspace, ensuring tests are isolated and can run in parallel.
• Naming Conventions:
  • Files: `feature-name.spec.ts` (e.g., `github-trigger.spec.ts`).
  • Test descriptions: Use `test('should ...')` format, describing the expected outcome.
• Independence & Parallelization:
  • All tests must be independent. Do not rely on the state from a previous test.
  • Create necessary data (like workspaces) programmatically in `beforeEach` or within the test itself. This is critical for parallel execution in CI.
  • Use `test.describe.configure({ mode: 'serial' })` ONLY if a sequence of tests is absolutely unavoidable.
• Error Handling: Use Playwright's built-in assertions. Add custom error messages for clarity where needed: `expect(locator, 'Error message here').toBeVisible();`.

```

---