Context
As part of the work on #55 (replacing the e2e cluster setup with nebari-dev/action-nebari-sandbox) I did a pass over all the workflows in this repo and found a few things worth cleaning up.
Clear duplicates
chart-lint runs twice on every charts/** change. Both webapi.yml and frontend.yml define an identical chart-lint job that runs helm lint charts/nebari-landing. They both trigger on charts/**, so any chart change kicks off two separate lint runs. Worth extracting into a standalone chart-lint.yml.
Note: automated-accessibility.yml was initially flagged as a duplicate of accessibility.yml but they are actually different workflows — automated-accessibility.yml is the automated PR gate (push-triggered, mock backend, npm run e2e), while accessibility.yml is a manual-only workflow targeting a live cluster with real credentials. Not a duplicate.
Significant overlap (worth discussing, not necessarily fixing now)
dev-watch-test.yml and screenshots.yml both do a full minikube cluster bootstrap — same Makefile steps, same ~15 min setup, just for different things on top. Once #55 lands and we standardize on action-nebari-sandbox, it's worth revisiting whether either of these still needs to exist in their current form (see also #57 for dev-watch-test.yml specifically).
webapi.yml and frontend.yml have ~150 lines of near-identical multi-arch Docker build + manifest logic. Only the image name and Dockerfile path differ. Not urgent, but a composite action would make future changes to the build strategy a one-line edit instead of a two-file edit.
sync-helm-chart.yml and release.yml both trigger on release published and both patch charts/nebari-landing/Chart.yaml. They run in parallel with no dependency, so sync can read a stale chart version if it wins the race against release.yml's publish-chart job. Low probability in practice, but worth sequencing properly.
Proposal
Context
As part of the work on #55 (replacing the e2e cluster setup with
nebari-dev/action-nebari-sandbox) I did a pass over all the workflows in this repo and found a few things worth cleaning up.Clear duplicates
chart-lintruns twice on everycharts/**change. Bothwebapi.ymlandfrontend.ymldefine an identicalchart-lintjob that runshelm lint charts/nebari-landing. They both trigger oncharts/**, so any chart change kicks off two separate lint runs. Worth extracting into a standalonechart-lint.yml.Note:
automated-accessibility.ymlwas initially flagged as a duplicate ofaccessibility.ymlbut they are actually different workflows —automated-accessibility.ymlis the automated PR gate (push-triggered, mock backend,npm run e2e), whileaccessibility.ymlis a manual-only workflow targeting a live cluster with real credentials. Not a duplicate.Significant overlap (worth discussing, not necessarily fixing now)
dev-watch-test.ymlandscreenshots.ymlboth do a full minikube cluster bootstrap — same Makefile steps, same ~15 min setup, just for different things on top. Once #55 lands and we standardize onaction-nebari-sandbox, it's worth revisiting whether either of these still needs to exist in their current form (see also #57 fordev-watch-test.ymlspecifically).webapi.ymlandfrontend.ymlhave ~150 lines of near-identical multi-arch Docker build + manifest logic. Only the image name and Dockerfile path differ. Not urgent, but a composite action would make future changes to the build strategy a one-line edit instead of a two-file edit.sync-helm-chart.ymlandrelease.ymlboth trigger onrelease publishedand both patchcharts/nebari-landing/Chart.yaml. They run in parallel with no dependency, so sync can read a stale chart version if it wins the race againstrelease.yml'spublish-chartjob. Low probability in practice, but worth sequencing properly.Proposal
chart-lintinto a standalone workflow triggered only oncharts/**chart-lintjob fromwebapi.ymlandfrontend.yml