ensures builds succeed after repo restructure

Author: colinjlacy

.github/workflows/publish-ghcr-images.yml

@@ -6,17 +6,11 @@ on:
       - main
     paths:
       - ".github/workflows/publish-ghcr-images.yml"
-      - "platform/kratix/promises/redis/pipeline/**"
-      - "platform/kratix/promises/cilium-api-access/pipeline/**"
-      - "platform/kratix/promises/cilium-namespace-lockdown/pipeline/**"
-      - "platform/kratix/promises/s3-bucket/pipeline/**"
-      - "platform/kratix/promises/application-release/pipeline/**"
-      - "demo/aws-sdk-go-v2/**"
-      - "platform/demo/provider/todos-api/**"
-      - "go/apps/request-logger-http/**"
-      - "go/runtimeconditions/**"
-      - "go/go.mod"
-      - "go/go.sum"
+      - "demos/kratix/promises/redis/pipeline/**"
+      - "demos/kratix/promises/application-release/pipeline/**"
+      - "demos/apps/todos-api/**"
+      - "demos/apps/request-logger-http/**"
+      - "extensions/**"
   workflow_dispatch:
 
 permissions:
@@ -32,26 +26,17 @@ jobs:
       matrix:
         image:
           - name: redis-pipeline
-            context: platform/kratix/promises/redis/pipeline
-            file: platform/kratix/promises/redis/pipeline/Dockerfile
-          # - name: cilium-api-access-pipeline
-          #   context: platform/kratix/promises/cilium-api-access/pipeline
-          #   file: platform/kratix/promises/cilium-api-access/pipeline/Dockerfile
-          # - name: cilium-namespace-lockdown-pipeline
-          #   context: platform/kratix/promises/cilium-namespace-lockdown/pipeline
-          #   file: platform/kratix/promises/cilium-namespace-lockdown/pipeline/Dockerfile
-          # - name: s3-bucket-pipeline
-          #   context: platform/kratix/promises/s3-bucket/pipeline
-          #   file: platform/kratix/promises/s3-bucket/pipeline/Dockerfile
+            context: demos/kratix/promises/redis/pipeline
+            file: demos/kratix/promises/redis/pipeline/Dockerfile
           - name: application-release-pipeline
-            context: platform/kratix/promises/application-release/pipeline
-            file: platform/kratix/promises/application-release/pipeline/Dockerfile
+            context: demos/kratix/promises/application-release/pipeline
+            file: demos/kratix/promises/application-release/pipeline/Dockerfile
           - name: todos-api
-            context: platform/demo/provider/todos-api
-            file: platform/demo/provider/todos-api/Dockerfile
+            context: demos/apps/todos-api
+            file: demos/apps/todos-api/Dockerfile
           - name: request-logger
             context: .
-            file: go/apps/request-logger-http/Dockerfile
+            file: demos/apps/request-logger-http/Dockerfile
 
     steps:
       - name: Check out source

README.md

@@ -1,6 +1,6 @@
 # Runtime Conditions Profilers
 
-Declare your service’s dependencies in code (Go or Python) and automatically generate the configurations needed for deployment. No YAML or manual steps required: just run a command in your CI pipeline to produce a spec that downstream tools (Kubernetes, Cilium, databases, etc.) can consume.
+Declare your service's runtime dependencies in code and generate a Runtime Conditions Profile that downstream tools can consume. The Go AST profiler reads first-party extension declaration packages and emits profile YAML for adapters and validators.
 
 ## The Problem
 
@@ -10,11 +10,11 @@ Downstream tooling is often a patchwork of one-off configurations and fragmented
 
 ## The Proposal
 
-This tool replaces chaos and confusion with a [three-step workflow](https://colinjlacy.github.io/runtime-conditions-profiles/):
+This repository is organized around a [three-step workflow](https://colinjlacy.github.io/runtime-conditions-profiles/):
 
-- The source code uses integrations. For an example, the demo app below calls an HTTP API, Redis, and S3.
+- The source code uses integrations. For an example, the demo app calls an HTTP API and Redis.
 - A generator emits a profile that includes requirements and environment variable names, not target values.
-- An adapter fulfills the profile. The Kratix demo maps Conditions to Redis, S3, Secrets, ConfigMaps, and Cilium policies.
+- An adapter fulfills the profile. The Kratix demo assets map Conditions to platform resources such as Redis, ConfigMaps, Secrets, and network policy.
 
 ## Who Benefits
 
@@ -37,17 +37,20 @@ This tool replaces chaos and confusion with a [three-step workflow](https://coli
 
 ## Contents
 
-This repository contains three separate implementation areas:
+This repository contains:
 
 - `ebpf-profiler/` - the original Linux eBPF runtime observation profiler.
-- `go/` - Go declaration library, Go AST profiler, and Go sample services.
-- `python/` - Python declaration library, Python AST profiler, and Python sample services.
+- `docs/` - the Runtime Conditions Profile specification draft and authoring guides.
+- `extensions/` - first-party extension definitions and their Go declaration packages.
+- `go/profiler/` - the maintained Go AST profile generator.
+- `demos/apps/` - demo workloads used to exercise declaration packages and downstream adapters.
+- `demos/kratix/` - Kratix adapter and Promise demo assets.
+- `examples/sdks/` - SDK packaging examples for package-owned manifests.
 
-The Runtime Conditions Profile specification draft lives in `docs/`. Start with
-`docs/intro.md` for the core spec, extension drafts, and SDK integration guides.
+The Runtime Conditions Profile specification draft lives in `docs/fifth-draft.md`.
 
 The GitHub Pages reader site lives in `site/`. It is a static site that presents
-the current spec, extension model, implementation guides, and end-to-end Kratix
+the spec, extension model, implementation guides, and end-to-end Kratix
 demo as a cohesive reader flow. The workflow in `.github/workflows/pages.yml`
 publishes that directory to GitHub Pages.
 
@@ -65,19 +68,12 @@ The generated eBPF bindings are produced by `bpf2go` from `ebpf-profiler/pkg/pro
 ## Go AST Profiler
 
 ```sh
-cd go
+cd go/profiler
 go test ./...
-go run ./profiler -dir ./apps/traffic -name traffic-generator
-docker compose up
-```
-
-## Python AST Profiler
-
-```sh
-cd python
-python3 -m unittest discover -s tests
-python3 -m runtimeconditions.profiler -d apps/traffic -n traffic-generator
-docker compose up
+go run . \
+  -dir ../../demos/apps/request-logger-http \
+  -name request-logger-http \
+  -workload-version dev
 ```
 
 ## Try It Out

docs/core/kratix-runtime-conditions-implementation-proposal.md

@@ -57,14 +57,14 @@ Those are important, but they should come after the first executable proof.
 The target outcome is a repeatable demo command that deploys a real application to Kubernetes through Kratix:
 
 ```bash
-rc deploy ./go/apps/request-logger \
+rc deploy ./demos/apps/request-logger-http \
   --image ghcr.io/example/request-logger:dev \
   --namespace demo
 ```
 
 That command should:
 
-1. run the Go or Python AST profiler
+1. run the Go AST profiler
 2. generate a Runtime Conditions Profile
 3. create or update a Kratix `ApplicationRelease` resource request
 4. wait for Kratix workflow completion
@@ -449,11 +449,9 @@ The application should not be deployed with a known incompatible API contract.
 ## Proposed Repository Layout
 
 ```text
-platform/
+demos/
   README.md
   kratix/
-    install/
-      quickstart.md
     promises/
       redis/
         promise.yaml
@@ -470,34 +468,27 @@ platform/
       todos-api.catalog-info.yaml
       todos.openapi.yaml
       todos.openapi.breaking.yaml
-  demo/
-    provider/
-      todos-api/
-        main.go
-        Dockerfile
-        k8s.yaml
-    consumer/
-      go/
-        main.go
-        Dockerfile
-      python/
-        main.py
-        Dockerfile
-    scripts/
-      smoke-test.sh
-      break-openapi.sh
+  apps/
+    todos-api/
+      main.go
+      Dockerfile
+      k8s.yaml
+    request-logger-http/
+      main.go
+      conditions.go
+      Dockerfile
 ```
 
-The existing Go and Python profilers can stay in their language-specific trees. The new `platform/` tree should contain the Kratix-specific implementation and demo assets.
+The Go profiler stays in `go/profiler`. Kratix-specific implementation and demo assets live under `demos/kratix`.
 
 ## CLI Responsibilities
 
 The `rc deploy` command should be a thin automation wrapper around existing tools.
 
 It should:
 
-1. detect Go or Python source
-2. run the correct AST profiler
+1. detect Go source
+2. run the Go AST profiler
 3. produce the Runtime Conditions Profile
 4. create the `ApplicationRelease` request
 5. apply it with `kubectl`

docs/guides/generator-discovery-workflow.md

@@ -47,80 +47,55 @@ The current Go demo generator performs these steps:
 
 The generator does not need `-extensions-root` for package manifests shipped by imported SDK packages.
 
-The `-extensions-root` flag remains useful for local extension catalogs and legacy binding manifests, but SDK package manifests are discovered from imports.
+The `-extensions-root` flag is useful for local extension catalogs and manifests loaded from explicit extension roots, while SDK package manifests are discovered from imports.
 
 ---
 
 # 3. Demo Walkthrough
 
-The demo workload imports a local SDK package:
+The current request logger demo imports explicit first-party declaration packages:
 
 ```go
-import "github.com/colinjlacy/golang-http-profiler/demo/aws-sdk-go-v2/service/s3"
+import (
+	common "github.com/colinjlacy/runtime-conditions-profiles/extensions/common-integrations/go"
+	env "github.com/colinjlacy/runtime-conditions-profiles/extensions/env-configuration/go"
+)
 ```
 
-The workload calls the SDK normally:
+The workload declares an HTTP API and Redis cache:
 
 ```go
-func writeAuditLog(ctx context.Context, event string) error {
-	bucket := os.Getenv("AUDIT_LOG_BUCKET")
-	if bucket == "" {
-		return errors.New("AUDIT_LOG_BUCKET is not set")
-	}
-	client := s3.NewFromConfig(s3.Config{})
-	_, err := client.PutObject(ctx, &s3.PutObjectInput{
-		Bucket: stringPtr(bucket),
-		Key:    stringPtr("request-logger/demo.json"),
-		Body:   strings.NewReader(event),
-	})
-	return err
-}
-```
-
-The SDK package includes:
-
-```text
-demo/aws-sdk-go-v2/service/s3/
-  client.go
-  runtimeconditions.package.yaml
-  aws-object-store-v1alpha1.yaml
-```
-
-The package manifest maps `Client.PutObject` to:
+common.API("todos-api",
+	common.Spec("openapi", "catalog://api/default/todos-api", "1.0.0"),
+	common.GET("/todos/{id}", common.Response[Todo]()),
+	env.Env("baseUrl", "TODOS_API_URL"),
+)
 
-```yaml
-kind: aws.object_store
-interfaceType: aws.s3
-configuration:
-  env:
-    - property: bucket
-      name: AUDIT_LOG_BUCKET
-    - property: region
-      name: AWS_REGION
-    - property: accessKeyId
-      name: AWS_ACCESS_KEY_ID
-      sensitive: true
-    - property: secretAccessKey
-      name: AWS_SECRET_ACCESS_KEY
-      sensitive: true
+common.Cache("request-cache",
+	common.KeyValue(common.Redis),
+	env.EnvAlternative(env.Env("url", "REDIS_URL")),
+	env.EnvAlternative(
+		env.Env("hostname", "REDIS_HOST"),
+		env.Env("port", "REDIS_PORT"),
+	),
+)
 ```
 
 Running the generator:
 
 ```sh
-cd go
-go run ./profiler \
-  -dir ./apps/request-logger-http \
+cd go/profiler
+go run . \
+  -dir ../../demos/apps/request-logger-http \
   -name request-logger-http \
   -workload-uri github.com/example/request-logger-http \
   -workload-version v0.1.0
 ```
 
-produces a profile that includes both explicit declarations and SDK-discovered Conditions:
+produces a profile that includes the directly used declaration package extensions:
 
 ```yaml
 extensions:
-  - https://aws.example.com/runtimeconditions/object-store:v1alpha1
   - https://runtimeconditions.io/extensions/common-integrations:v1alpha1
   - https://runtimeconditions.io/extensions/env-configuration:v1alpha1
 
@@ -148,41 +123,22 @@ conditions:
               name: REDIS_HOST
             - property: port
               name: REDIS_PORT
-  - name: s3-object-store
-    kind: aws.object_store
-    interface:
-      type: aws.s3
-      bucketClass: standard
-    configuration:
-      env:
-        - property: bucket
-          name: AUDIT_LOG_BUCKET
-        - property: region
-          name: AWS_REGION
-        - property: accessKeyId
-          name: AWS_ACCESS_KEY_ID
-          sensitive: true
-        - property: secretAccessKey
-          name: AWS_SECRET_ACCESS_KEY
-          sensitive: true
 ```
 
-The `todos-api` and `request-cache` Conditions come from explicit `rc` declarations in the workload. The `s3-object-store` Condition comes from normal SDK usage plus the SDK package manifest.
+The `todos-api` and `request-cache` Conditions come from explicit first-party declaration package calls in the workload. A workload that also imports an SDK package with a manifest can emit additional SDK-discovered Conditions from that SDK usage.
 
 The profile records the environment variable names expected by the workload. It does not contain the values for those variables. In the Kratix demo, the runtime-workload adapter maps these requested properties to provider-owned outputs:
 
 | Condition property | Kubernetes source |
 | ---- | ---- |
 | `baseUrl` | Literal service URL from the API catalog |
 | `url`, `hostname`, `port` | Redis Promise connection ConfigMap |
-| `bucket`, `region` | S3Bucket Promise connection ConfigMap for the provisioned AWS bucket |
-| `accessKeyId`, `secretAccessKey` | S3Bucket Promise credentials Secret for the generated bucket-scoped IAM access key |
 
 The same adapter emits Cilium policy requests for the resolved workload:
 
 - A `CiliumNamespaceLockdown` request creates namespace default-deny pod networking.
 - A `CiliumAPIAccess` request is emitted for API Conditions that declare HTTP operations. That request contains the workload selector, resolved service or FQDN destination, port, and only the `method` and `path` pairs declared by the Condition.
-- Redis and S3Bucket requests include the workload selector so their Promises can render dependency-specific Cilium policies.
+- Redis requests include the workload selector so their Promises can render dependency-specific Cilium policies.
 
 The generator still emits only the Runtime Conditions Profile. Network-policy requests are adapter output.
 

docs/guides/package-artifact-conventions.md

@@ -81,7 +81,7 @@ The package MAY include one or more language-specific sections. A generator igno
 
 # 3. Go Section
 
-The current demo implements a Go section.
+The current example implements a Go section.
 
 ```yaml
 go: