-
Notifications
You must be signed in to change notification settings - Fork 6
fix: add memory configuration for tvm actions #191
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
Conversation
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.
Copilot reviewed 2 out of 3 changed files in this pull request and generated no comments.
Files not reviewed (1)
- .gitattributes: Language not supported
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #191 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 12 12
Lines 391 391
Branches 41 41
=========================================
Hits 391 391 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…t deployment limitation)
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.
This is in the reference to the other comments on this and the related pr.
I think this produces more future work/maintenance/complexity that is not required. If in the future we want to treat 1 of these actions differently, say for example azure-blob needs more or less memory we need to create independent env keys for each action, then independent env values for each in vault, and read them all independently ... etc.
The alternative is to just store this non-secret directly in manifest.yml and be done with it.
This is what we do already with runtime: nodejs:22, each action can have a different node version ... which is not unlike having different memory requirements.
moritzraho
left a comment
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.
approved, while I generally agree with Jesse to configure this in the manifest.
it could be useful to have the memory configurable on deployment to hotfix the service in case of oom issues and buy us some time to find the root cause
|
I am setting the memory limits for an action directly in the manifest. Here the goal was to increase the limits for one action, |
purplecabbage
left a comment
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.
This is great, it is simple and focused. Do we want to take this opportunity to bump the others to 512 to be safe?
My issue was not that we were moving all actions to 1024, it was simply that we were giving up the flexibility of being able to modify them independently.
|
We haven't had an issue with the other actions so far, but they do share the same potentially problematic code (lru-cache, metrics) so I'll bump them to the next level as well. |
How Has This Been Tested?
Will be tested in a dev/stage deployment.
Types of changes
Checklist: