Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

feat(pipelineRef): Replace PipelineTrigger with PipelineRef for Spinnaker UI #4842

Open
wants to merge 8 commits into
base: master
Choose a base branch
from

Conversation

edgarulg
Copy link
Contributor

@edgarulg edgarulg commented Feb 18, 2025

Feature: Performance Optimization for Nested Pipelines in Spinnaker Orca
In Spinnaker, pipelines with many nested child pipelines (e.g., Pipeline → Pipeline → Pipeline → Pipeline) can cause significant delays in loading times, particularly for large instances. This is because the Spinnaker UI often needs to load parent executions for any pipeline that was triggered by another, which unnecessarily increases the load on the Orca execution repository.

Solution:
To address this issue, I’ve introduced an optimization using the PipelineRef feature that was previously delivered. The idea is to propagate the PipelineRef trigger instead of the full PipelineTrigger for nested pipelines. This reduces the load on Orca and improves UI performance.

How It Works:

ExecutionRepository Update:
I added a new flag, includeNestedExecutions, to the retrieve method of the ExecutionRepository interface.

Default Behavior:
Existing execution repository implementations don’t need to change.

  • The default behavior remains to use the normal retrieve method.

SqlExecutionRepository Logic:
The only repository that requires an update is the SqlExecutionRepository, where the business logic for includeNestedExecutions is implemented.

  • If includeNestedExecutions is true, Orca will convert any PipelineRefTrigger into a PipelineTrigger to ensure nested executions are returned.

  • If the flag is false, Orca will return executions with the PipelineRefTrigger.

SPeL Compatibility:
To maintain backward compatibility with Spinnaker’s SPeL, the OrcaMessageHandler ensures that nested executions are included when evaluating any expressions. This guarantees that SPeL expressions still resolve correctly.

SPeLAutoComplete Compatibility:
The SPeLAutoComplete feature continues to work as expected. The endpoint that retrieves previous executions to feed the autocomplete is still retrieving executions with the full execution context, including nested executions. This ensures that the autocomplete functionality is unaffected by the performance improvement.

Summary:
The main idea is to minimize unnecessary load on Orca by returning a PipelineRefTrigger for external requests, while keeping full execution context for internal modules that need it. This change significantly reduces the pressure on the Orca execution repository and improves UI performance, especially in large Spinnaker instances.

This performance improvement is backward compatible, and SPeLAutoComplete continues to function as expected, with no disruption to existing Spinnaker functionality.

How to enable it

executionRepository:
  redis:
    enabled: false
  sql:
    enabled: true
    pipelineRef:
      enabled: true

Here is an example on how the Spinnaker UI looks like when a pipeline is triggered by another pipeline:
Captura de pantalla 2025-02-17 a la(s) 8 26 28 p m

Here is another example on how the execution looks like if we inspect it in the Spinnaker UI:
Captura de pantalla 2025-02-17 a la(s) 8 26 50 p m

Finally here is another example that probes the SPeLAutoComplete still works by converting PipelineRefTrigger to PipelineTrigger and existing SPeLs still works as expected:
Captura de pantalla 2025-02-17 a la(s) 8 31 20 p m

@edgarulg
Copy link
Contributor Author

I will add more tests around TaskController and endpoints.

@edgarulg
Copy link
Contributor Author

I added all tests I have in mind for this feature. This is ready now.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants