[INFRA-421] support repos with no launch.yaml

[dmartschenko]

Clever Coding Standards Agreement

• Author and Review Statement, "We agree this code adheres to our Clever Global Coding Standards and other applicable Coding Standards"

JIRA

https://linear.app/clever/issue/INFRA-421/update-circle-ci-orbs-to-work-with-no-launchyaml-files

About

goci previously only built apps configured via Catapult launch configs. This PR adds support for apps configured for Kubernetes via stack.yaml, and handles repos with a mix of both.

In this PR:

• Discovers and builds apps from both config/ (Kubernetes) and launch/ (Catapult), merging results with Kubernetes winning when the same app appears in both
• Kubernetes apps skip the Catapult publish and deploy steps
• Fails when a Kubernetes config exists for an app but is missing a build command that the legacy Catapult config had — forces migration to be completed explicitly
  • Will work on this ticket first to prevent hard blockers: https://linear.app/clever/issue/INFRA-420/move-kubernetes-migrated-apps-to-new-launch-gen-version
• Only errors if both config directories are missing; a missing config/ or launch/ alone is silently ignored

Important

This PR proposes adding a build block to the stack.yaml files for kubernetes apps. It would be configured as such

build:
  command: make build
  dockerfile: Dockerfile
  artifactName: my-app
  dependencies:
    - src/**
    - go.mod

Checklist

• Increment the version number in VERSION
• Add release notes

Testing

• Removed launch.yaml, migrated to new launch-gen, and verified cci builds for slingshot
• Verified cci builds for groups which has catapult + kubernetes apps

[andruwm]

Kubernetes apps skip the Catapult publish

Will we be fully migrating all envs for an app under the new migration plan? Otherwise, we may still need catapult publish

[dmartschenko]

Will we be fully migrating all envs for an app under the new migration plan? Otherwise, we may still need catapult publish

Say more. I may be missing context here

[andruwm]

Will we be fully migrating all envs for an app under the new migration plan? Otherwise, we may still need catapult publish

Say more. I may be missing context here

In the original migration plan, I believe that personal environments were still going to be running on Fargate? If that is the case for the updated migration plan, then we still need catapult builds to be published.

[dmartschenko]

In the original migration plan, I believe that personal environments were still going to be running on Fargate? If that is the case for the updated migration plan, then we still need catapult builds to be published.

Ahh good call out. Personal environments for migrated apps can easily be supported on k8s. Devs would just specify their personal environment when launching an app from Backstage. Unless there are scale concerns I would opt to route folks to backstage so we're not in a halfsies migration state for each app

[andruwm]

In the original migration plan, I believe that personal environments were still going to be running on Fargate? If that is the case for the updated migration plan, then we still need catapult builds to be published.

Ahh good call out. Personal environments for migrated apps can easily be supported on k8s. Devs would just specify their personal environment when launching an app from Backstage. Unless there are scale concerns I would opt to route folks to backstage so we're not in a halfsies migration state for each app

After the data-stage discussion today, it sounds like we will need to support fargate a while longer. Maybe we should only skip catapult publish if there is no launch config left?

[dmartschenko]

After the data-stage discussion today, it sounds like we will need to support fargate a while longer. Maybe we should only skip catapult publish if there is no launch config left?

fking datastage... yes I'll make the change to only skip if launch config doesn't exist