You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 81e8156
Browse filesBrowse the repository at this point in the historyBrowse files
Copy file name to clipboardExpand all lines: CONTRIBUTING-DFO.md
+18-14Lines changed: 18 additions & 14 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,7 +9,7 @@ The DFO's Data Commons instance, meaning the mixer and the graph-serving layer u
9
9
Two kinds of code live here, and they behave differently.
10
10
11
11
-**Upstream code.** Everything outside `custom_dc/` tracks datacommonsorg/website and the `mixer` and `import` submodules. We take changes from upstream; we do not write them here.
12
-
-**ONE Data code.** Everything under `custom_dc/` is ours (for the DFO). `custom_dc/dfo/prototypes` is the frontend, and `custom_dc/api_server` holds a legacy copy of the Search API that stays until its removal PR lands. Upstream never touches these paths, so an upstream sync cannot conflict with work there.
12
+
-**ONE Data code.** Everything under `custom_dc/` is ours (for the DFO). `custom_dc/dfo/prototypes` is the frontend. Upstream never touches these paths, so an upstream sync cannot conflict with work there.
13
13
14
14
The repo builds one container image. A sibling repo, `infra`, deploys it to Cloud Run. This repo builds and pushes an image, and `infra` runs it.
15
15
@@ -25,8 +25,6 @@ feat/* ──► dev ──► main
25
25
dfo-dev dfo-prod
26
26
```
27
27
28
-
`customdc_stable` is not a tier. It mirrors upstream's stable release channel and serves as the reference point for `just sync`.
29
-
30
28
## Where your work goes
31
29
32
30
The loop is short.
@@ -44,34 +42,39 @@ The loop is short.
44
42
45
43
## Taking upstream changes
46
44
47
-
Upstream sync is a step on `dev`, not a separate long-lived branch.
45
+
`dev` tracks Data Commons Platform (DCP) releases. `infra` pins a DCP version as `dcp_version` in `infra/stacks/dcp/variables.tf`, and `dev` carries the website and mixer that release was built from. A sync is a merge of that website commit into `dev`, so `dev` shares history with datacommonsorg/website.
48
46
49
47
```sh
50
48
git checkout dev
51
-
git fetch upstream
52
-
just sync # shows what changed since the last sync
53
-
git merge upstream/master
54
-
git submodule update --init --recursive
49
+
just sync 1.1.6 # merge the website commit DCP 1.1.6 was built from
55
50
```
56
51
57
-
Merging upstream's website also moves the `mixer`and `import` submodule pointers, because upstream pins them. **Website and submodules must move together.**
52
+
`just sync` stops on conflicts. `just sync-resolve` takes upstream's side for every path outside `.dfo-protected-paths` and leaves the protected ones for you. After resolving those, `git add` them and run `just sync-finish`. `just sync-abort` drops the merge. Once committed, the recipe checks out the submodules and runs `just check-overrides`, which lists the seam files in `.dfo-overridden-files` that upstream changed across the sync.
58
53
59
54
### Matching a Data Commons Platform release
60
55
61
-
`infra` pins a DCP version (`1.1.x`) for the Terraform stack, and the image this repo builds has to match it. A website tag alone will not tell you which mixer that release runs. Google builds the release image from a website tag plus a mixer commit that runs ahead of what the tag pins. DCP 1.1.2 was built from website `v3.5.7` with mixer `79627f8`, while `v3.5.7` itself pins mixer `051d8ff`.
56
+
The website and mixer move as a pair, and the pairing comes from the release image. Each image `gcr.io/datcom-ci/datacommons-services:<version>` records its source commits as the `WEBSITE_HASH` and `MIXER_HASH` build args. A website tag pins one mixer, and Google can build a release with a newer one. DCP 1.1.2 was built from website `v3.5.7` with mixer `79627f8`, while `v3.5.7` pins mixer `051d8ff`.
57
+
58
+
`just dcp-pair <version>` prints the pairing:
59
+
60
+
```sh
61
+
$ just dcp-pair 1.1.6
62
+
website=9852134
63
+
mixer=8118587
64
+
```
62
65
63
-
That mapping exists only inside the published image, as build args:
66
+
It reads the image config from the registry, the same as:
To move to a new DCP release, read `WEBSITE_HASH` and `MIXER_HASH` off that release's image, merge the website commit, then set the `mixer` pointer to `MIXER_HASH`. Taking the mixer the website tag carries instead builds a pairing Google never tested against that release's Terraform stack.
75
+
`just sync` merges `WEBSITE_HASH`, sets the `mixer` pointer to `MIXER_HASH`, and sets the `import` pointer to the one the website commit pins. It fails if the image or either build arg is missing. Taking the mixer the website tag carries builds a pairing Google never tested against that release's Terraform stack.
73
76
74
-
`.github/workflows/codeql-analysis.yml`, `dependabot-approval.yml`, and `submodule-update.yml` are deleted in this fork. All three guard their jobs on `github.repository == 'datacommonsorg/website'`, so they never run here. Upstream re-adds them on every sync that touches them. Keep them deleted rather than resolving the conflict toward upstream's version.
77
+
`.github/workflows/` is DFO-owned. A workflow file upstream adds there would run on the fork, so a sync takes nothing from upstream under that directory. `just sync` and `just sync-finish` reset it to the pre-merge version and list every file upstream added, changed, or deleted there. Port one by hand in its own PR if the fork needs it. Upstream's `codeql-analysis.yml`, `dependabot-approval.yml`, and `submodule-update.yml` stay deleted this way.
75
78
76
79
## Releasing to production
77
80
@@ -109,5 +112,6 @@ always reproducible from a committed sha.
109
112
110
113
-**Commits** follow [Conventional Commits](https://www.conventionalcommits.org): `feat:`, `fix:`, `chore:`, and so on.
111
114
-**PRs target `dev`.** Only the release step writes to `main`.
115
+
-**PRs into `dev` land as merge commits.** The `dev` ruleset allows only merges. A sync commit's second parent is the upstream website commit, and that parent is what keeps the fork's history shared with datacommonsorg/website. A squash or rebase drops it, and the next sync merges from an older base and replays upstream changes the fork already has as conflicts.
112
116
-**Delete merged branches.** Feature branches are short-lived.
113
117
-**Keep internal notes out of the repo.** Design docs, plans, and audits stay local. This guide and real reference docs are the exception.
Copy file name to clipboardExpand all lines: README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ New here? Read [CONTRIBUTING-DFO.md](./CONTRIBUTING-DFO.md) before opening a bra
6
6
7
7
## Layout
8
8
9
-
-**`custom_dc/`** is ONE Data's DFO code. `custom_dc/dfo/prototypes` is the frontend, and `custom_dc/api_server` holds a legacy copy of the Search API that stays until its removal PR lands. The Search API and Datasets API are built in [apis](https://github.com/DevelopmentFinanceObservatory/apis). Upstream never touches these paths.
9
+
-**`custom_dc/`** is ONE Data's DFO code. `custom_dc/dfo/prototypes` is the frontend. The Search API and Datasets API are built in [apis](https://github.com/DevelopmentFinanceObservatory/apis). Upstream never touches these paths.
10
10
-**Everything else** tracks upstream `datacommonsorg/website`, with the graph server (`mixer`) and ingestion (`import`) as submodules.
0 commit comments