devops-lib-gcp/ai-blitz/task-05-cloudFunctionCICD-implementation.md

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.