# Task 05: Implement the `cloudFunctionCICD` skeleton

- **Type:** Small feature
- **Source:** `BUGS_AND_IMPROVEMENTS_REPORT.md` §1.6 (`cloudFunctionCICDFlow()` is currently a stub containing only `sh 'ls -al'; echo 'Hello World'`)

## Goal

`vars/cloudFunctionCICD.groovy` actually deploys a GCP Cloud Function. Services that use `cloudFunctionCICD { ... }` get a working pipeline instead of the current no-op skeleton.

## Acceptance Criteria

- [ ] `vars/cloudFunctionCICD.groovy` exposes `def call(Map param)` (not the current zero-arg `cloudFunctionCICDFlow()`), accepting at minimum:
  - `repo_name`
  - `function_name`
  - `runtime` — one of `nodejs20` / `python311` / `go121` / etc.
  - `entry_point`
  - `region`
  - `service_account`
  - `maintainer`
- [ ] Stages run in this order:
  1. `checkOut` (reuse `src/com/meesho/stages/checkOut.groovy`)
  2. Optional: `buildObjHelper.run(param.runtime)` if the runtime needs a transpile/install step (e.g. `node-*` → `npm install && npm run build`). Else skip.
  3. `gcloud functions deploy ${function_name} --gen2 --runtime ${runtime} --entry-point ${entry_point} --region ${region} --service-account ${service_account} --source .`
  4. `notify` (reuse `src/com/meesho/stages/notify.groovy`) — same Slack format as `buildPipeline`
- [ ] Pod selection uses `libraryResource("org/meesho/${env.INFRA_ENV}-pod.yaml")` — never an inline `podTemplate`
- [ ] Auth: `gcloud` uses ambient Workload Identity via the pod's `service_account`; **no key files written to disk**
- [ ] Branch gating: only deploy from `master`, `main`, `gcp-main`, or `gcp-master` (match the JFrog/S3 gate in `buildMaven.groovy`) unless `param.deploy_from_any_branch == true`
- [ ] Deployment-tracker callback fires on success/failure (reuse `notify.groovy:postTrackingApi`)
- [ ] One real consumer service uses the new entry point end-to-end as the smoke test
- [ ] `README.md` `## Adding this library to a new service` gains a Cloud Function example block alongside the existing Jenkinsfile sample
- [ ] `docs/architecture.md` § "Entry points (vars/)" updated — `cloudFunctionCICD` is no longer flagged as "stub"
- [ ] `BUGS_AND_IMPROVEMENTS_REPORT.md` §1.6 entry is moved to a Resolved section (or struck-through per repo convention)
- [ ] `docs/index.md` / `docs/wiki/index.md` updated if the entry point gets new dedicated documentation

## Notes / known gotchas

- Use `gcloud functions deploy --gen2` explicitly — gen-1 syntax differs (no `--source .`, different IAM model). Don't write code that works on whichever version happens to be default in the build-tools image.
- The user-authorization gate from `eksCICD.groovy:12-26` (allowed-users list, Ringmaster banner) is intentionally **not** copied to this entry point unless DevOps says otherwise. Cloud Functions are deployed less frequently; the gate may be overkill.
- If `runtime` doesn't match a known `buildObjHelper` case (e.g. `python311` vs `python-3.11`), prefer extending the `buildObjHelper` switch to recognise the GCP runtime naming rather than inlining build logic in `cloudFunctionCICD`.
- This task touches a lot of files (vars/, README, architecture.md, BUGS report) — chunk into reviewable commits if the agent is going autonomous, otherwise one PR is fine.