feat(xnat): install plugins from S3 (per-plugin source:s3 + s3.syncPrefix)#32
Merged
Conversation
kathrynalpert
force-pushed
the
feat/xnat-s3-plugin-install
branch
from
b5735d4 to
29fa0a6
Compare
Add an S3 source to the plugin-installer seam so a deployer can stage plugin jars to a bucket and have them pulled in-cluster with the AWS CLI (pod IRSA role), no registry/credentials required: - per-plugin `source: s3` -> `aws s3 cp <uri>` (uri defaults to s3://<pluginInstaller.s3.bucket>/<prefix>/<target>, or per-plugin s3Uri) - `pluginInstaller.s3.syncPrefix: true` -> one init container copies the whole s3://<bucket>/<prefix>/ tree into the plugins dir (no per-plugin list) Coordinates/url/file source forms and the image form are unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
andrey-embarklabs
approved these changes
Jun 24, 2026
- Chart.yaml 2.0.0 -> 2.2.0: the version must exceed the highest published tag (xnat-2.1.0) or chart-releaser cuts no new tag on merge, leaving nothing for a consumer to pin the s3 plugin-install feature to. - syncPrefix: make pluginInstaller.s3.prefix required. An empty prefix made 'aws s3 cp --recursive s3://<bucket>//' copy the WHOLE bucket into the plugins dir; now it fails fast at render.
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
2 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.
What
Adds an S3 source to the chart's plugin-installer seam so a deployer can stage plugin jars to a bucket and have them pulled in-cluster by the AWS CLI using the pod's IRSA role — no registry/credentials in the cluster.
source: s3(per plugin) →aws s3 cp <uri>; URI defaults tos3://<pluginInstaller.s3.bucket>/<prefix>/<target>(per-plugins3Urioverrides).pluginInstaller.s3.syncPrefix: true→ one init container copies the wholes3://<bucket>/<prefix>/tree into the plugins dir (no per-plugin list).New values:
pluginInstaller.s3.{image,bucket,prefix,region,syncPrefix}(imagedefaults topublic.ecr.aws/aws-cli/aws-cli).Why
Useful for any deployer who builds/stages plugin jars to object storage (e.g. a release pipeline) and wants the test/runtime cluster to pull the exact staged bytes via IRSA rather than resolve from Maven/registries at boot.
Compatibility
Additive. The existing
coordinates/url/filesource forms and the OCIimageform render unchanged; the new init containers only appear whensource: s3/syncPrefixare set. Verified withhelm lint+helm template(image form byte-identical to baseline).🤖 Generated with Claude Code