feat: Add AWS CodePipeline Retry Stage Execution component

[manasa-bhagwat]

Implements #2753

This PR adds the aws.codepipeline.retryStageExecution component, which retries a specific stage in an existing AWS CodePipeline execution using the RetryStageExecution API.

What

The component retries a stage using either FAILED_ACTIONS or ALL_ACTIONS and emits retry metadata for downstream workflow steps. It is a synchronous one-shot action — no polling/EventBridge lifecycle. The pipelineExecutionId field supports expressions, enabling dynamic wiring from preceding steps (for example Run Pipeline).

Backend

• pkg/integrations/aws/codepipeline/retry_stage_execution.go — component implementation (all core.Component methods)
• pkg/integrations/aws/codepipeline/client.go — RetryStageExecution() client method + response struct
• pkg/integrations/aws/codepipeline/retry_stage_execution_test.go — Setup + Execute tests
• pkg/integrations/aws/codepipeline/example_output_retry_stage_execution.json — example output
• pkg/integrations/aws/codepipeline/example.go — ExampleOutput() wiring
• pkg/integrations/aws/aws.go — registered in Components()

Frontend

• web_src/src/pages/workflowv2/mappers/aws/codepipeline/retry_stage_execution.ts — canvas mapper
• web_src/src/pages/workflowv2/mappers/aws/index.ts — registered mapper + state registry

Docs

• docs/components/AWS.mdx — generated with make gen.components.docs

Tests

• Setup: invalid config, missing region, missing pipeline, missing stage, missing pipelineExecutionId, invalid retryMode, valid config
• Execute: invalid config, missing credentials, API error path, valid request emits retry payload
• Metadata/interface: name/label/description/icon/color, required config fields, default output channel

Demo

[Updated]

Retry.Stage.Execution.-.Demo.SuperPlane.mp4

[manasa-bhagwat]

Hi @forestileao

This is pr ready for review when you get a chance.

Adds the Retry Stage Execution component.

Happy to iterate based on feedback.

---

[UPDATE - CI has been re-run and all checks are now passing.]

Note about failed CI job:

One CI failure (make test.setup) is not related to this feature logic.

I’m not fully clear on the infrastructure-related failures flagged in the failed test. So, I’ve intentionally avoided modifying infra-specific files to prevent unintended side effects.

I’d appreciate it if this could be resolved as part of the review and merge process.

[manasa-bhagwat]

Hey @forestileao

Similar to the stage and pipelineExecution updates in retryStageExecution, I’d like to roll this pattern out across other CodePipeline components as well, where applicable.

I believe using FieldTypeIntegrationResource consistently should reduce user overhead, avoid manual copy/paste errors, and improve config UX across the integration.

If you agree, I can do it in a follow-up PR and roll it out component by component.

[forestileao]

@manasa-bhagwat If possible that would be a really nice improvement. Just judge if it makes sense to apply the pattern in the component you are working on 😉

[manasa-bhagwat]

@manasa-bhagwat If possible that would be a really nice improvement. Just judge if it makes sense to apply the pattern in the component you are working on 😉

Thanks for the suggestion, @forestileao

I’ve opened a follow-up PR for this: #3279.

I reviewed all 5 CodePipeline components:

• Updated: get_pipeline_execution.executionId → FieldTypeIntegrationResource (codepipeline.pipelineExecution)
• No changes needed in: get_pipeline, run_pipeline, retry_stage_execution (already aligned), and on_pipeline (kept predicate-based filtering by design)

[forestileao]

@manasa-bhagwat All good and working. Thanks for the contribution!