Add reusable workflows - #11
Conversation
…alidation, and release automation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| key: kubeconform-schemas-${{ inputs.kubeconform_version }}-${{ hashFiles('charts/**/Chart.yaml') }} | ||
| restore-keys: | | ||
| kubeconform-schemas-${{ inputs.kubeconform_version }}- |
There was a problem hiding this comment.
📝 Info: kubeconform schema cache key is keyed only on Chart.yaml, not chart_glob
The cache key kubeconform-schemas-${{ inputs.kubeconform_version }}-${{ hashFiles('charts/**/Chart.yaml') }} hardcodes the charts/**/Chart.yaml glob, independent of the configurable chart_glob input. This works for both documented callers (single-chart charts/ → charts/Chart.yaml, and monorepo charts/*/ → charts/*/Chart.yaml, both matched by charts/**/Chart.yaml). It would only break for a caller whose charts live outside charts/, where hashFiles returns empty and the key collapses to a constant. Not a correctness issue because kubeconform re-downloads any missing schemas and restore-keys provides prefix fallback; noting for awareness in case chart layouts diverge from the two documented shapes.
Was this helpful? React with 👍 or 👎 to provide feedback.
| # Inject short commit SHA for CDN immutable path (matched by upload prefix). | ||
| if [[ "${INJECT_CDN_SHA}" == "true" ]]; then | ||
| SHORT_SHA="$(git rev-parse --short HEAD)" | ||
| yq -i ".cdn.commitSha = \"${SHORT_SHA}\"" "${CHART_DIR}/values.yaml" | ||
| fi |
There was a problem hiding this comment.
🔍 cdn.commitSha injected without the 'g' prefix used by the RC version
helm-publish injects cdn.commitSha as the raw git rev-parse --short HEAD (helm-publish.yaml:192-193), whereas oci-build.yaml:214 prefixes the short SHA with g for the RC version segment. These are intentionally different values (the RC version needs the g for SemVer §9 numeric-identifier validity, while the CDN path presumably uses the plain short SHA to match the upload prefix). Worth confirming the CDN upload destination_prefix in caller repos uses the plain (un-prefixed) short SHA so the chart's cdn.commitSha resolves to a path that actually exists.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
The g was added to prevent release-please actions being blocked by short_sha's that contain only numbers.
| OCI_BASE: oci://${{ env.REGISTRY }}/${{ github.repository }}/charts | ||
| IMAGE_BASE: ${{ env.REGISTRY }}/${{ github.repository }}/charts |
There was a problem hiding this comment.
📝 Info: OCI paths rely on github.repository already being lowercase
OCI_BASE/IMAGE_BASE interpolate ${{ github.repository }} directly (helm-publish.yaml:181-182), and release-retag/oci-build do the same for image refs. GHCR requires lowercase repository paths. This is safe for the bcit-tlu org (already lowercase) and matches the pre-existing oci-build.yaml convention, but any caller repo/org containing uppercase letters would produce an invalid OCI reference. Noting the shared assumption rather than flagging as a bug.
Was this helpful? React with 👍 or 👎 to provide feedback.
| - name: Run extra command | ||
| if: inputs.extra_command != '' | ||
| run: ${{ inputs.extra_command }} |
There was a problem hiding this comment.
🟨 Reusable workflow input interpolated directly into a shell run block
The extra_command input is expanded directly into the run: script via template interpolation (.github/workflows/helm-lint.yaml:121), so whatever string a caller supplies is executed verbatim as shell. Because the value is substituted before the shell sees it (rather than passed via an environment variable), any shell metacharacters in the input are interpreted, giving arbitrary command execution in the job. Callers of a reusable workflow are generally trusted, so impact is limited, but the pattern is fragile hardening-wise.
Was this helpful? React with 👍 or 👎 to provide feedback.
|
IMHO, I'd prefer to see an independent https://github.com/bcit-tlu/sugar-suite CI/CD pipeline until it is proven to work with CDN asset replacement. It would also be nice to be able to develop a solution for branch-based deployment, because local "previews" of features or fixes is less convenient (and problematic for mobile testing). I feel that there are too many moving parts at the moment ,and that before we standardize and consolidate, we should have a scalable solution that works really well that we can then use as the "golden record" for replication to other repos. |
2 participants
Close #10