fix(argo-cd): set EXTENSIONS_DIR so extensions install to the served path - #4068
Merged
Conversation
jmeridth
marked this pull request as ready for review
September 6, 2026 03:49
jmeridth
requested review from
mbevc1,
mkilchhofer,
tico24 and
yu-croco
as code owners
September 6, 2026 03:49
yu-croco
previously approved these changes
Sep 7, 2026
mbevc1
enabled auto-merge (squash)
September 7, 2026 06:16
…path What/Why The server.extensions feature mounted the shared volume at /tmp/extensions (where argocd-server discovers extensions) but the installer image copies into /tmp/extensions/resources by default, so installed extensions never loaded in the UI. Upstream made the target configurable via EXTENSIONS_DIR (argoproj-labs/argocd-extension-installer#14, shipped in the v1.1.0 image the chart now pins), and its docs prescribe /tmp/extensions for this chart's wiring. Set that env on every extension init container; entries from each extension's .env render after it and take precedence, and the .env block is now with-guarded so env-less extensions render validly. Proof it works helm template with an extensionList entry renders EXTENSIONS_DIR before the extension's own env, template comments do not leak into output, and ./scripts/lint.sh passes. Risk + AI role Low: only affects rendered env of the opt-in extensions init container; older pinned installer images ignore the unknown variable. AI-assisted (Claude Fable 5), maintainer-directed. Review focus Confirmation that /tmp/extensions (not /tmp/extensions/resources) is the path argocd-server serves from, per the upstream PR's documentation table naming this chart's defaults. Signed-off-by: jmeridth <jmeridth@gmail.com>
What/Why No chart template in this repo uses inline template comments in rendered blocks; the EXTENSIONS_DIR rationale lives in the commit and PR instead. Proof it works helm template output unchanged; ./scripts/lint.sh passes. Risk + AI role None beyond the parent change. AI-assisted (Claude Fable 5). Review focus None. Signed-off-by: jmeridth <jmeridth@gmail.com>
jmeridth
force-pushed
the
fix/extensions-dir-env
branch
from
September 8, 2026 12:24
8510769 to
2fa9f1e
Compare
Member
Author
|
Rebased onto main after #4070 took |
mkilchhofer
approved these changes
Sep 9, 2026
mbevc1
approved these changes
Sep 9, 2026
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3320
What/Why
server.extensionsmounted the shared volume at/tmp/extensions(where argocd-server discovers extensions) while the installer image copies into/tmp/extensions/resourcesby default, so installed extensions never loaded in the UI. Upstream made the target configurable viaEXTENSIONS_DIR(argoproj-labs/argocd-extension-installer#14, thanks @Sturgelose, shipped in the v1.1.0 image the chart pins since #4064), and its documentation prescribes/tmp/extensionsfor this chart's wiring. This sets that env on every extension init container. Entries from each extension's.envrender after it and take precedence, and the.envblock is nowwith-guarded so env-less extensions render validly.Proof it works
helm templatewith anextensionListentry rendersEXTENSIONS_DIRbefore the extension's own env, nothing leaks into output from the template comment, and./scripts/lint.shpasses. Older pinned installer images ignore the unknown variable, so pinningv1.0.1keeps exactly today's behavior.Risk + AI role
Low: only the opt-in extensions init container's rendered env changes. AI-assisted, maintainer-directed.
Review focus
@Sturgelose confirmation welcome that
/tmp/extensionsis the served path per your upstream docs table, since you authored both the report and the fix.Checklist: