More docs (mostly infra) and fixing CI configuration #2810
Conversation
atvaccaro
changed the title
atvaccaro
requested review from
lauriemerrell,
SorenSpicknall and
charlie-costanzo
as code owners
|
|
||
| 1. Building branches containing only a subset of repository contents (for example, a branch only including infra-related code) | ||
| * This action is called "projection" | ||
| 2. Bringing in contents from another repository without relying on published artifacts such as Helm charts |
There was a problem hiding this comment.
I am a little concerned about this re: handoff. cc @themightychris
Do we think it's appropriate or sustainable to hand off the project with this kind of dependency, particularly through an uncommon dependency mechanism (i.e., declared in places that are not necessarily standard/super visible to less experienced users)?
There was a problem hiding this comment.
Yeah but the alternatives aren't super great, they'd shift complexity to floating around in the cloud state and in people's heads rather than being baked into GitHub workflows. The goal of these architectures were expressly to solve for how to make the workflows live more inside GitHub and be more "solid state" so their more resilient against long-term churn in the ecosystem and handoffs between contributors. The lower adoption of this approach is of course a concern, but adding ArgoCD or Flux to the mix instead isn't an obvious win either—nor is keeping it all in GitHub Actions but importing tons of complex bash code into the local project to avoid dependencies.
There was a problem hiding this comment.
I think we could at least consider referencing the published helm charts rather than bring in the jarvus cluster template. Branch projections are more "obvious" IMO and matters for the gitops workflows. I think the main concern would be upstream changes (e.g. cluster-template) sneaking into cal-itp deploys without someone realizing; that's only relevant for cluster-template not for Actions.
|
Also not sure if/how this should interact with this existing docs page: https://docs.calitp.org/data-infra/infrastructure/README.html |
Ah good call, I'll move those where appropriate |
There was a problem hiding this comment.
I am approving but I still wonder how things here interact with this section on the docs page I linked before
|
Ah good catch thanks, I forgot to remove the old docs. |
Description
Describe your changes and why you're making them. Please include the context, motivation, and relevant dependencies.
Part of our general documentation focus this sprint.
Type of change
How has this been tested?
Include commands/logs/screenshots as relevant.
CI must pass.
Post-merge follow-ups
Document any actions that must be taken post-merge to deploy or otherwise implement the changes in this PR (for example, running a full refresh of some incremental model in dbt). If these actions will take more than a few hours after the merge or if they will be completed by someone other than the PR author, please create a dedicated follow-up issue and link it here to track resolution.
Deploy to prod