OpenHands Enterprise 1.2.1 release (chart 0.2.1)#264
Conversation
|
Looks like there are a few issues preventing this PR from being merged!
If you'd like me to help, just leave a comment, like Feel free to include any additional details that might help me get this PR into a better state. You can manage your notification settings |
|
@OpenHands please fix the failing actions on PR #264 at branch |
|
I'm on it! aivong-openhands can track my progress at all-hands.dev |
When both openhands and runtime-api charts are modified in a PR, the lint-and-test job needs to use the alpha version of runtime-api that was published in the publish-charts job. Without this fix, the openhands chart lint fails because it tries to download runtime-api version 0.1.21 which doesn't exist yet (only the alpha version 0.1.21-alpha.264 was published). Co-authored-by: openhands <openhands@all-hands.dev>
|
I've fixed the failing GitHub Actions on PR #264. The issue was in the Root Cause:
Fix Applied: Changes:
The fix has been pushed to the |
|
How would I go about steps 2 and 3 in the helm chart checklist? |
Checked 3 since fields have not changed for values.yaml configs |
Yes I think it's fine as is. They don't all have to be checked, they might not apply. |
|
When @chuckbutkus and I have worked with the LiteLLM charts one of the things that has annoyed us both is that you can't tell from looking at the chart version what the LiteLLM version is and so you have to drill in to figure it out which just adds friction to troubleshooting. It seems like we do a similar thing -- all though we do helpfully provide the app version in the chart which provides a bit quicker answer. What do you all think about moving toward chart versioning scheme that aligns at least first two digits of sym version between and chart and OpenHands/OpenHands version? We could even align all three digits and add --patch0,-patch1 suffix for chart only changes. WDYT? |
|
@jpshackelford I'm on board with the need of easily being able to tell what's in the release. Litellm version is a new example to me but it makes sense. I think there are other options besides a version convention we can consider for this so let's start with the goal. What information do you want to be able to easily pull from chart version? And if relevant, which of it is most important. |
|
Honestly, I think it might be easier to just have a wiki page with information on what sha is in each release. |
|
@jpshackelford @mamoodi could I get a review on the chart changes in this PR? |
|
Closing as the changes in this chart release seem stale now and we have an automated script to cut a new chart version! |
OpenHands/integrations-hub#264 removed the legacy unprefixed env-var fallbacks from the FastAPI backend, so the backend now reads only the INTHUB_-prefixed names. Two chart env vars were still using the old unprefixed names and would silently stop being read after #264 lands: - APP_ADMIN_EMAILS -> INTHUB_APP_ADMIN_EMAILS The admin allowlist would have gone empty, locking out /api/admin/* access in Kubernetes deployments. The backend now accepts comma-separated syntax for the prefixed name (it also accepts JSON arrays), so the old "use unprefixed because the SDK parser expects JSON" workaround is obsolete. - AUTH_REDIRECT_PROXY_URL -> INTHUB_OAUTH_REDIRECT_PROXY_URL Pre-existing mismatch: oauth_flow.py already read the prefixed name, so the proxy var was never wired through. Fixed here while aligning the rest of the chart with the INTHUB_*-only backend. Updated the header doc block in templates/_env.yaml to drop the removed fallback chain, and refreshed the matching comments in both the subchart values.yaml and the parent chart values.yaml. Bumped the openhands umbrella chart 0.7.76 -> 0.7.77 (required by the validate-chart-versions check since charts/openhands/values.yaml changed). The integrations-hub subchart itself is inert (version 0.0.0, ships at whatever openhands version bundles it). Co-authored-by: openhands <openhands@all-hands.dev>
#756) OpenHands/integrations-hub#264 removed the legacy unprefixed env-var fallbacks from the FastAPI backend, so the backend now reads only the INTHUB_-prefixed names. Two chart env vars were still using the old unprefixed names and would silently stop being read after #264 lands: - APP_ADMIN_EMAILS -> INTHUB_APP_ADMIN_EMAILS The admin allowlist would have gone empty, locking out /api/admin/* access in Kubernetes deployments. The backend now accepts comma-separated syntax for the prefixed name (it also accepts JSON arrays), so the old "use unprefixed because the SDK parser expects JSON" workaround is obsolete. - AUTH_REDIRECT_PROXY_URL -> INTHUB_OAUTH_REDIRECT_PROXY_URL Pre-existing mismatch: oauth_flow.py already read the prefixed name, so the proxy var was never wired through. Fixed here while aligning the rest of the chart with the INTHUB_*-only backend. Updated the header doc block in templates/_env.yaml to drop the removed fallback chain, and refreshed the matching comments in both the subchart values.yaml and the parent chart values.yaml. Bumped the openhands umbrella chart 0.7.76 -> 0.7.77 (required by the validate-chart-versions check since charts/openhands/values.yaml changed). The integrations-hub subchart itself is inert (version 0.0.0, ships at whatever openhands version bundles it). Co-authored-by: openhands <openhands@all-hands.dev>
Description
Jan 7 deploy repo release tag from https://www.notion.so/Release-Tracking-2767be798a178098a6faf5125721551c: 0.68.0
Automated chart updates from script created in #262
How the script was run:
Go to script directory:
cd scripts/update_openhands_chartsPass the deploy tag as an argument to the script:
The script makes changes to openhands and runtime-api chart files:
The changes were included as part of this PR.
Helm Chart Checklist
versionfield inChart.yamlfor each modified chartAdditional Notes