🔧 Chore Summary
Improve the IBM Cloud Code Engine deployment guide (Workflow A and Workflow B) to address two gaps discovered during end-to-end testing of PR #6289:
Workflow A's "Typical first deploy" sequence is missing a registry pull secret creation step - make ibmcloud-deploy fails with Referenced image registry access secret not found if the secret doesn't exist yet
Workflow B uses $IBMCLOUD_* variables throughout but never tells users to export .env.ce to their shell - the Makefile loads it automatically but manual CLI users get empty variables and confusing failures
🧱 Area Affected
Choose the general area(s) that this chore affects:
⚙️ Context / Rationale
Discovered during live end-to-end verification of PR #6289 on IBM Cloud Code Engine (eu-de, contextforge-proj).
Gap 1 — Registry secret missing from Workflow A:
Workflow A jumps from make ibmcloud-push to make ibmcloud-deploy with no step to create the registry pull secret. Workflow B covers this in step 6 but Workflow A has no equivalent. The fix is either a docs note or having make ibmcloud-deploy auto-create the registry secret the same way it auto-creates the env secret.
Gap 2 — .env.ce not exported in Workflow B:
Workflow B CLI commands reference $IBMCLOUD_REGISTRY_SECRET, $IBMCLOUD_IMAGE_NAME, $IBMCLOUD_API_KEY etc. but the guide never tells users to load .env.ce into their shell. Users get empty variables and failures like Required flag "name" not set. A single export line at the top of Workflow B would fix this:
export $(grep -v '^#' .env.ce | grep -v '^$' | xargs)
📦 Related Make Targets
Reference any relevant Makefile targets that are involved, if applicable. Ex:
make ibmcloud-deploy - should optionally auto-create registry secret if missing
make ibmcloud-push - registry secret creation logically belongs before this or after it
📋 Acceptance Criteria
Define what "done" looks like for this task.
🧩 Additional Context
Verified on macOS (Apple Silicon), IBM Cloud eu-de region, Code Engine project contextforge-proj. Both gaps are pre-existing and were not introduced by PR #6289.
🔧 Chore Summary
Improve the IBM Cloud Code Engine deployment guide (Workflow A and Workflow B) to address two gaps discovered during end-to-end testing of PR #6289:
Workflow A's "Typical first deploy" sequence is missing a registry pull secret creation step - make ibmcloud-deploy fails with Referenced image registry access secret not found if the secret doesn't exist yet
Workflow B uses $IBMCLOUD_* variables throughout but never tells users to export .env.ce to their shell - the Makefile loads it automatically but manual CLI users get empty variables and confusing failures
🧱 Area Affected
Choose the general area(s) that this chore affects:
Makefile⚙️ Context / Rationale
Discovered during live end-to-end verification of PR #6289 on IBM Cloud Code Engine (eu-de, contextforge-proj).
Gap 1 — Registry secret missing from Workflow A:
Workflow A jumps from make ibmcloud-push to make ibmcloud-deploy with no step to create the registry pull secret. Workflow B covers this in step 6 but Workflow A has no equivalent. The fix is either a docs note or having make ibmcloud-deploy auto-create the registry secret the same way it auto-creates the env secret.
Gap 2 — .env.ce not exported in Workflow B:
Workflow B CLI commands reference $IBMCLOUD_REGISTRY_SECRET, $IBMCLOUD_IMAGE_NAME, $IBMCLOUD_API_KEY etc. but the guide never tells users to load .env.ce into their shell. Users get empty variables and failures like Required flag "name" not set. A single export line at the top of Workflow B would fix this:
export $(grep -v '^#' .env.ce | grep -v '^$' | xargs)📦 Related Make Targets
Reference any relevant Makefile targets that are involved, if applicable. Ex:
make ibmcloud-deploy- should optionally auto-create registry secret if missingmake ibmcloud-push- registry secret creation logically belongs before this or after it📋 Acceptance Criteria
Define what "done" looks like for this task.
🧩 Additional Context
Verified on macOS (Apple Silicon), IBM Cloud eu-de region, Code Engine project contextforge-proj. Both gaps are pre-existing and were not introduced by PR #6289.