-
Notifications
You must be signed in to change notification settings - Fork 467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable client-side caching for some orchestrators #3235
Disable client-side caching for some orchestrators #3235
Conversation
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am not 100% sure about this, could we not potentially modify the entrypoint
s that we use for these orchestrators to mimic the behavior of the other orchestrators?
Returns: | ||
Whether the orchestrator supports client side caching. | ||
""" | ||
# The Kubernetes orchestrator starts step pods from a pipeline pod. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be nice to write these messages as logger.debug(...)
IMO.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, if we had more time there would be multiple solutions for this, but all of them take days of effort as far as I can see.
I'm always a little sceptical to have log messages on simple properties. Why would it log something each time a boolean is read? We don't even know who tries to access it. What do you think instead if we add a log if we skip client-side caching for some reason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I chose the wrong place to post this comment. What I meant was, how about we display this message (in the commented-out section) as a debug
message only once when a pipeline is executed? Otherwise, I agree with you. Displaying it every time someone accesses it, is a bad idea.
Describe changes
Client-side caching is failing for orchestrators that don't follow our usual process of creating an orchestrator intermediate representation and then forwarding that to the orchestrator.
Instead, these orchestrators have their own entrypoint that runs in one environment and spins up additional environments for the actual steps to run. There is no easy solution to make this work with the client-side caching implementation, which is why I disabled it for these orchestrators for now.
Pre-requisites
Please ensure you have done the following:
develop
and the open PR is targetingdevelop
. If your branch wasn't based on develop read Contribution guide on rebasing branch to develop.Types of changes