added files

2026-08-26 02:02:24 +05:30
parent 58ee8a276a
commit 3419cfba0c
200 changed files with 22132 additions and 0 deletions
@@ -0,0 +1,53 @@
+<!-- m-wiki: type=concept slug=build-dispatch topic=build base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
+
+> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources.
+
+# Build Dispatch
+
+`buildObjHelper.run(build_tool)` maps a `build_tool` string from `config.yaml` to a concrete builder class instance using a Groovy `switch/case` with regex patterns.
+
+## Where it applies in this repo
+
+`src/com/meesho/stages/buildObjHelper.groovy:run`
+
+The full dispatch table (in order, first match wins):
+
+| Pattern | Builder class |
+|---------|--------------|
+| `maven` (exact) | `buildMaven` |
+| `docker` (exact) | `buildDocker` |
+| `~/^maven-.*/` | `buildMaven` |
+| `~/^python-.*/` | `buildPython` |
+| `~/^node-.*/` | `buildNode` |
+| `~/^rust.*/` | `buildRust` |
+| `~/^go.*/` | `buildGo` |
+| `gradle` (exact) | `buildGradle` |
+| `php` (exact) | `buildPhp` |
+| default | `defaultBuild()` |
+
+Each builder is instantiated fresh per build — no shared state between builds.
+
+## Why this design
+
+Groovy `switch/case` evaluates patterns top-to-bottom and returns on the first match. Regex patterns (the `~/…/` syntax) cover version-suffixed variants like `go-1.22`, `node-20`, `python-3.12` without requiring an exhaustive case list. The exact-match cases for `maven` and `docker` appear before the regex catch-all `~/^maven-.*/` to handle the legacy bare-string case.
+
+If no case matches, `defaultBuild()` is called without logging a warning — the pipeline reports success with no artifact produced. A typo in `config.yaml` (e.g. `golang` instead of `go`) produces this silent no-op. If a build succeeds but produces no Docker image, check `build_tool` spelling in `config.yaml` first.
+
+## Related
+
+- [Build stages](../03-BUILD-STAGES.md) — broader build lifecycle
+- [Language builds](../07-LANGUAGE-BUILDS.md) — per-language builder details
+
+## Sources
+
+(no raw/ sources at bootstrap)
+
+## Notes
+
+<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
+
+---
+
+[← Wiki index](../../index.md)
+
+<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->
@@ -0,0 +1,46 @@
+<!-- m-wiki: type=concept slug=config-only-detection topic=build base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
+
+> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources.
+
+# Config-Only Change Detection
+
+When a commit only changes YAML config files (no source code), each language builder skips the compile/test/image-build steps and instead fetches the last-built image tag from GAR (Google Artifact Registry). This avoids rebuilding identical binaries when only configs changed.
+
+## Where it applies in this repo
+
+Implemented independently in each language builder (`src/com/meesho/stages/buildMaven.groovy`, `buildGo.groovy`, `buildNode.groovy`, etc.).
+
+The detection pattern varies slightly by builder but follows the same logic:
+
+1. Run `git diff HEAD~1 -- configs/` (or `git diff ORIG_HEAD -- configs/`).
+2. If the diff is non-empty AND no source files changed → set `appConfigChanges = true`, skip compilation.
+3. Fetch the latest image tag from the artifact bucket (S3 or GCS) or GAR.
+4. Set `env.TAG` to the fetched tag.
+5. Proceed directly to `deployArgoCD.run()`.
+
+The check is gated by `skip_s3_check` in `config.yaml`. Setting `skip_s3_check: true` forces a full rebuild even when only configs changed.
+
+## Why this design
+
+Config-only deployments are common at Meesho (dynamic config updates, feature flags). Rebuilding the entire Java or Go binary for a one-line YAML change wastes 3–10 minutes. By reusing the last image tag and skipping straight to ArgoCD deploy, the pipeline completes in ~1 minute for config-only changes.
+
+The detection relies on `git diff` against the previous commit, so it only works when the commit history is linear. Force-pushes or squash merges may produce false negatives (full rebuild triggered unnecessarily).
+
+## Related
+
+- [Language builds](../07-LANGUAGE-BUILDS.md) — where this check is embedded per builder
+- [Build dispatch](build-dispatch.md) — the builder instance that contains this check
+
+## Sources
+
+(no raw/ sources at bootstrap)
+
+## Notes
+
+<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
+
+---
+
+[← Wiki index](../../index.md)
+
+<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->
@@ -0,0 +1,57 @@
+<!-- m-wiki: type=concept slug=docker-tagging topic=build base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
+
+> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources.
+
+# Docker Tagging
+
+`getDockerParams.getTag()` produces the Docker image tag for each build. The tag format encodes the version, commit SHA, and a timestamp to guarantee uniqueness across rebuilds of the same commit.
+
+## Where it applies in this repo
+
+`src/com/meesho/utilities/getDockerParams.groovy:getTag`
+
+**Standard builds:**
+```
+v{pom-version or package-version}-{7-char-sha}-{epoch-ms}
+```
+Example: `v1.4.2-a3f8c21-1714920000000`
+
+**Toolchain builds** (when `env.INFRA_ENV == 'toolchain'`):
+```
+v{version}-{7-char-sha}
+```
+Example: `v1.4.2-a3f8c21`
+
+The short SHA comes from `git log -1 --format=%h` (7 chars). The full 40-char SHA is also captured in `env.commit_id` as a side effect of `getCommitid()`.
+
+Version is read from:
+- `pom.xml` → `xq -r .project.version pom.xml`
+- `package.json` → `jq -r .version package.json`
+- Default: `1.0`
+
+**Hotfix Maven builds** override the tag format to `v{version}-HOT` (set directly in `buildMaven.run()`, not via `getTag`).
+
+## Why this design
+
+The epoch-ms suffix ensures that two builds from the exact same commit produce different tags. This is intentional: if a build fails mid-way and is retried, the retry must produce a new image (the previous one may be partially pushed or broken). Without the timestamp, `docker push` on a retry would be a no-op if the tag already exists.
+
+Toolchain builds omit the timestamp because toolchain images are content-addressed: the same source commit must always produce the same tag so toolchain consumers can pin to a stable reference without tracking timestamps.
+
+## Related
+
+- [Language builds](../07-LANGUAGE-BUILDS.md) — each builder sets `env.TAG` using getTag
+- [Notifications](../10-NOTIFICATIONS.md) — `env.TAG` is included in Ringmaster and Slack payloads
+
+## Sources
+
+(no raw/ sources at bootstrap)
+
+## Notes
+
+<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
+
+---
+
+[← Wiki index](../../index.md)
+
+<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->
@@ -0,0 +1,49 @@
+<!-- m-wiki: type=concept slug=node-paired-files topic=build base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
+
+> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources.
+
+# Node Build: Paired File Rule
+
+`src/com/meesho/stages/buildNode.groovy` and `resources/com/meesho/node-Dockerfile` are paired files. Changes to Node install logic in one must be mirrored in the other to avoid a split-brain build path.
+
+## Where it applies in this repo
+
+`src/com/meesho/stages/buildNode.groovy:buildDckr`
+`resources/com/meesho/node-Dockerfile`
+
+## How they interact
+
+`buildNode.groovy` detects the package manager at runtime (npm vs pnpm vs yarn) and passes the install command to the Dockerfile as the `npm_install_arg` template variable. The Dockerfile's `else` branch handles the fallback when no explicit or detected command is provided (currently `npm ci`).
+
+```
+buildNode.buildDckr(config):
+  ├─ Detect package manager → npm_install_arg = "pnpm install" | "npm ci" | ...
+  ├─ constructTemplate.renderTemplate(binding, 'node-Dockerfile')
+  │    └─ binding.npm_install_arg → substituted into node-Dockerfile
+  └─ docker build -f Dockerfile ...
+```
+
+When `npm_install_arg` is not set in `config.yaml`, `buildNode.groovy` falls back to its own detection logic. The Dockerfile default branch handles the case where detection produces nothing.
+
+## Why this matters
+
+If `buildNode.groovy` changes the fallback install command or adds support for a new package manager, the Dockerfile default branch must be updated in the same PR. Changing only one file leaves them out of sync: the runtime path may succeed while the Docker fallback uses the old command (or vice versa). This creates subtly different images depending on whether `npm_install_arg` is explicitly configured.
+
+## Related
+
+- [Language builds](../07-LANGUAGE-BUILDS.md) — Node builder overview
+- [Dockerfile templates](../08-DOCKERFILE-TEMPLATES.md) — how renderTemplate works
+
+## Sources
+
+(no raw/ sources)
+
+## Notes
+
+<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
+
+---
+
+[← Wiki index](../../index.md)
+
+<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->
@@ -0,0 +1,54 @@
+<!-- m-wiki: type=concept slug=scm-variable-scope topic=build base-sha=28f54cf7bef9 generated-at=2026-05-12T00:00:00+00:00 sources=[] -->
+
+> Generated 2026-05-12 at base-sha 28f54cf7bef9. Type: concept. 0 sources.
+
+# SCM Variable Scope
+
+The `scm` variable is only available inside consumer Jenkinsfiles, not inside `vars/` or `src/` of the shared library. Referencing it in library code causes a runtime `MissingPropertyException`.
+
+## Where it applies in this repo
+
+`vars/eksCICD.groovy` and all files under `src/com/meesho/`
+
+## Why `scm` is unavailable
+
+The `scm` variable (branch, remote URL, credentials) is injected by the GitHub Branch Source plugin into **consumer Jenkinsfiles** at the time they are loaded by Jenkins. Library code (everything under `vars/` and `src/`) is a separate classloader context — the plugin does not inject `scm` there.
+
+Attempting to access `scm.branches` or `scm.userRemoteConfigs` from library code will throw:
+
+```
+MissingPropertyException: No such property: scm for class: groovy.lang.Binding
+```
+
+## Correct alternatives
+
+Inside library code, use the Jenkins-injected environment variables instead:
+
+| Need | Use instead of `scm.*` |
+|------|------------------------|
+| Branch name | `env.BRANCH_NAME` |
+| Repository URL | `env.GIT_URL` |
+| PR number | `env.CHANGE_ID` |
+| PR source branch | `env.CHANGE_BRANCH` |
+| PR target branch | `env.CHANGE_TARGET` |
+
+All of these are set by the GitHub Branch Source plugin before library code runs.
+
+## Related
+
+- [Entry points](../02-ENTRYPOINTS.md) — where this constraint applies
+- [Environment mapping](../05-ENVIRONMENT-MAPPING.md) — `env.CHANGE_ID` is the PR-build detector
+
+## Sources
+
+(no raw/ sources)
+
+## Notes
+
+<!-- Anything below is human-owned. wiki-init never reads or modifies content under this heading. -->
+
+---
+
+[← Wiki index](../../index.md)
+
+<!-- atomic: keep this page ≤600 words. New scope → new concept page that builds on this one. Do not append paragraphs here. -->