diff --git a/.github/config/.pyspelling.yml b/.github/config/.pyspelling.yml index c3ba3d87..64b4d933 100644 --- a/.github/config/.pyspelling.yml +++ b/.github/config/.pyspelling.yml @@ -1,28 +1,29 @@ +--- matrix: -- name: Markdown - aspell: - lang: en - d: en_US - dictionary: - encoding: utf-8 - wordlists: - - .github/config/en-custom.txt - pipeline: - - pyspelling.filters.context: - context_visible_first: true - delimiters: - # Remove markdown image links: ![alt text](path/to/image.png) - - open: '!\[' - close: '\)' - - pyspelling.filters.markdown: - markdown_extensions: - - markdown.extensions.fenced_code - - pyspelling.filters.html: - comments: false - ignores: - - code - - pre - - pyspelling.filters.url - sources: - - '**/*.md' - default_encoding: utf-8 + - name: Markdown + aspell: + lang: en + d: en_US + dictionary: + encoding: utf-8 + wordlists: + - .github/config/en-custom.txt + pipeline: + - pyspelling.filters.context: + context_visible_first: true + delimiters: + # Remove markdown image links: ![alt text](path/to/image.png) + - open: '!\[' + close: '\)' + - pyspelling.filters.markdown: + markdown_extensions: + - markdown.extensions.fenced_code + - pyspelling.filters.html: + comments: false + ignores: + - code + - pre + - pyspelling.filters.url + sources: + - "**/*.md" + default_encoding: utf-8 diff --git a/.github/config/en-custom.txt b/.github/config/en-custom.txt index cf8a9dca..8d3ffa58 100644 --- a/.github/config/en-custom.txt +++ b/.github/config/en-custom.txt @@ -1,1274 +1,1284 @@ -attestation -attestations -Buildx -GoReleaser -prerelease -QEMU -SBOM AAD +ACA +ACA +ACI +ACI +aci +aci +ACICompute +ACMEv +AcMEv +AcquireLock ACR +acr +additionalProperties +addon +Aditi +af AKS +aks +Alibaba +allowPlatformOptions +ALPN +amazonaws +amazonaws +AmazonECS AmazonS +amd +amongst +Analytics +analytics +AnonymousCredential +api +apiGroup +apiGroups +apiKey +APIReference APIs +apis +apiserver +apiVersion +apiVersions APPBASE +AppCore +appID +appId +appId +ApplicationGraph +ApplicationGraphConnection +ApplicationGraphOutputResource +ApplicationGraphResource +ApplicationGraphResponse +applicationName +ApplicationResource +ApplicationsCore +ApplicationsRP +appmodel +appname +appPort +approver +approvers +ArgoCD args +ARM +ArmResourceActionSync +armrpc +ARM's +arn +arns aspell -azurecr -Analytics +aspirationally +AssumeRole +AssumeRoleProvider +assumeRoleProvider +assumeRoleProviders Async Async +async +attestation +attestations +Auditability +auth +auth +authenticator +AuthN +Authorizer +authType +AuthZ +autocompletion +autorest +autoscaler +autoscaling +awk +aws +AWSCredential +AWSCredentialProvider +AWSCredentialProvider +awsIRSA AWSSimpleQueueService -overconsume +az Azure -SQLServer -subcomponents +azure +azurecr +AzureDevOps +AzureDevops +azureDNS +azureFederatedIdentity +azurekv +AzurePublicCloud +azurerm +AzureRM +azureWorkloadIdentity +AzWI +backend +backendContainer +backendRef +backendrequest +backendRoute +backends +backoff +balancer +Balancer +balancers +BaseOptions +BasicAuth +basicAuthentication +basicAuthentication +Beenham +behaviour +benefitted +bicepAuthentication +bicepAuthentication +bicepConfig +bicepconfig +bicepparam +BicepRecipeProperties +bicepSettings +bicepSettings +Bitbucket Blazor +boolean brooke -clusterissuer -tcpreplay -DDoS -ClusterIssuer +btn +Buildx +BYO +CADL +camelCased +cardinality +cardpane +carte +cas +Casper +catalogued +categorizeby +cd +cd +cdf +CEL +centric +certificateFrom +changelog +changelogs +Chawla +checksums +CidrBlock +ciphertext +cleartext CLI -golang +cli +clientID +clientId +ClientSecret CLIs +CloudFormation +CloudRun +CloudRun +ClusterIP +clusterissuer +ClusterIssuer +clusterName +ClusterResourceCheck +ClusterRole +ClusterRoleBinding CMD -CQRS -CRDs -CRON -CRUDL -CSI -CTRL +CNAMEd +CNCF +CockroachDB +codebase +codebases Codegen +codegen +codeql Codespace +codespace Codespaces -codeql -CosmosDB +codespaces +codetab +commonName +componentName +componentname +computeRecipePack +compute's +confi +confidentialCompute +config +ConfigLoader +ConfigMaps +configs +ConfigStructure +configurationStores +connectionString +connectionStrings +ContainerApps +ContainerGroupProfile +containerGroupProfile +containername +containerPort +contoso +contourclient +contrib +ControlPlaneHealthCheck +Convertor +CoPilot corepack Corepack +corerp +cosmosAccount +CosmosDB +cosmosdb +cpu +CQRS +CrashLoopBackOff +CRD +crd +CRD +CRDs +CRDs CreateOrUpdate -Datastores -DDD -dep -deps -deserialize -desynchronization -devcontainer -devDependencies -devcontainers -dirs -DNS -dns -DaemonSet -Dapr -Dapr's -Deployable -Dockerfiles -Docsy -DocumentDB -EKS -eksClusterName -emptyDir -entrypoint -EOF -Extensibility -FileShare -Fluentd -FTEs -GKE -GOAPP -GitHubAccess -Hostname -html -HttpRoute -HttpRoutes -Kibana -IAM -IaC -InternalServerError -IoT -JSON -JSON -KeyVault -Kinesis -kubeconfig -Kubernetes -ListSecret -Liveness -LocalID -maxReplicas -MONGOMODULE -MQ -MacOS -MemoryDB -MemoryDB -Microservice -Mongo -MongoDb -NAV -NODEAPP -NodeJS -nodeSelector -OAuth -OCI -OIDC -OUTRESOURCE -OUTVALUES -PARAMS -PYTHONAPP -PowerShell -Pre -PubSub -PVCs -persistentVolumes -PersistentVolumeClaims -ProjectRadius -Quickstart -Quickstarts -RBAC -RabbitMQ -ResourceDeploymentClient -Rollout -SaaS -schema's -SDKs -secretId -SecretProviderClass -SMTP -SNI -SQL -SQS -SQSDeveloperGuide -SSL -STATESTORE -StatefulSet -StatefulSets -apiVersions -openAPIV -OAI -af -oas -readmeio -additionalProperties -inheritence -polymorphism -readOnly -StatusCode -Subnet -SubnetGroup -Subnets -Swappable -TBD -TCP -Terraform -TLS -ToCs -UCP -UDP -UI -URIs -VPC -VSCode -VSIX -WSL -addon -aks -api -appID -appId -appId -appPort -appmodel -appname -arn -async -auth -auth -awk -aws -az -azure -backend -btn -cardpane -cas -centric -cli -clusterName -codebase -codegen -codespace -codespaces -codetab -componentName -componentname -config -connectionString -containerPort -containername -corerp -cosmosAccount -cosmosdb +CreateOrUpdateEnvironment +CreateResource +creationPolicy +CRON +Crossplane +crt +CRUDL +crypto +cryptographic +Cryptographic +cryptographically +CSI +CSR +ctnr +CTRL +ctx +CustomConfigValidationCheck +customizable customizations +CustomResourceDefinitions +DaemonSet +daemonset +Damle +Dapr dapr +daprd +daprextension daprPubSubBrokers +daprrp +Dapr's daprSecretStores +daprSidecar daprStateStores -daprd daprstatestores daprstatestores +Dariusz +darwin databaseAccounts +datacenters +Datadog +dataflow +dataflows +datamodel +DataModel +dataRecipePack datastore +Datastores +datastores +DBA +DBAs +DBAs +DDD +DDoS de +debuggable declaratively +decrypt decrypted +decrypts +deduplicated +DefaultClient +defaultCpu +defaultMemoryInGB +defaultSku +deletable +dep +Dependabot +dependabot +Dependabot +dependabot +Deployable deployable +Deployer +deployer +deployers +DeploymentResource +DeploymentTemplate +deployTo +deps +deserialization +deserialize +desynchronization dev +devcontainer +devcontainers +devDependencies +developerguide +DevOps +digestable +DigitalOcean +dir +dirs +discoverability +discoverable +distroless +DML +DNS +dns +dnsNames +Dockerfile +Dockerfiles +docRadAppDevTLS +Docsy docsy -eCommerce -eShop -eShopOnContainers -eShopOnDapr +DocumentDB +DoS +Dq +DriverWithSecrets +dropdown +DSL +E2E eachother +eBPF +EBS +eCommerce +ECR +ecr +ECS +ecs eg +EKS eks +eksClusterName eksctl -env -environmentId -eshop -exe -extensibility +emptyDir +enablement +encodings +eng +engs +Entra +Entra +entrypoint +enum +env +env: +environmentId +EnvironmentVariables +environmentVariables +envVariables +EOF +ePMKNy +ErrImagePull +eShop +eshop +eShopOnContainers +eShopOnDapr +Etag +etag +ETag +ETags +etcd +etcd's +exe +ExecuteOptions +Extensibility +extensibility +ExternalSecret +facto +failover failureThreshold +Fargate +Fargate +FileShare fileshare +filesystem +finalizer +finalizers +FindSecretIDs +FindSecretIds +fluentbit +Fluentd +fluentd +Flux +fluxcd +formData +formData +FQDN +fqdn +freeform frontend +frontendContainer +frontendRoute +frontloaded +FTEs fullyQualifiedHostname +func +gapped +gapped +GarbageCollectResources +gatewayUrl +GCP +generalizable +Genericize +genericized geos +getGraph +getMetadata +GetResource +gg +ghcr github +GitHubAccess githubPath -gotestsum githubRepo +Gitlab gitmodules +GitOps +gitops +GitRepository gitsubmodule +GKE +GOAPP +golang gomod +GoReleaser +GoReleaser +GoReleaser's +gotestsum +GPUs +Grafana +grafana +gRPC +gtwy +guid +gz hamilton handoff +hardcoded hardcoding +HashiCorp +hashicorp +healthz +Helly +helmclient +Hiremath +Homebrew +hostable +hostedZoneName +Hostname hostname hostName hostnames -hugo -http +howto html -httpRoutes +html +http +httpconf +httpGet +HTTPProxy +httpproxy +HttpRoute httproute +HTTPRoute +HTTPRoute +httpRouteConfig +HttpRoutes +httpRoutes https +hugo hyperscale +IaC iac +IAM iam +IAMs icecream +idempotency +IDEs +idl +idleConnection +IdP ified +ImagePullBackOff +impactful +implementers +incentivize infrastructure +inheritence init +initContainer initialDelaySeconds +inmemory integrations +integrators +intellisense +IntelliSense +interactor +InternalServerError +interop +interruptible +intra +invariants io +IoT +IPs +IRSA +IRSA +IsControlledBy +ISPs +ISRG +issuerRef +Istio +ISV +ISV +ISVs +Jaeger +jaeger +jargons +JetStream +Jira +jira js +JSON +JSON json +jsonResponse jumpbox +kachawla kafka +Karishma +keyspace +KeyVault keyvault +KeyVault +Kibana +Kinesis +Knative +KRM +kube +Kubebuilder kubeconf -kubecontext +kubeconfig kubeConfig +kubecontext kubectl +kubeproxy +Kubernetes kubernetes +KubernetesCompute +kubernetesMetadata +kubernetesMetadata +kubernetesmetadata kubernetesNamespace +Kumar +Kustomize +kustomize +KV +lakshmimsft +lakshmimsft +letsencrypt lifecycle lifecycles linkTitle linter linux +ListSecret +listSecrets +Liveness liveness -lrt livenessProbe +LLM +loadBalancer +loadSecrets +LoadSecrets +localhost +LocalID +localWorkspace +locational lockfile lockfiles Lockfiles -localWorkspace -localhost +lrt +MacOS macOS macos +magpieimage Makefile Makefiles +managedIdentity managedStore +manualProvisioning +manualResourceProvisioning +manualscale +manualScaling +mapsTo +masse +maxReplicas md +memcached +MemoryDB +MemoryDB memorydb +memoryInGB +metadataPolicy +Microservice microservice microservice microservices microsoft +minikube +minimumProtocolVersion +mins +Misconfiguration +misconfiguration +Misconfigurations +mitigations +Mitigations +MitM mk -Monorepo -monorepos +Mongo mongo -mongoDB mongoDatabase mongoDatabases +MongoDb +mongoDB mongodbDatabases +MONGOMODULE +Monorepo +monorepos mountPath +MQ +mTLS +multitenancy mux myaccount myapp +mycache mycluster +Mycompany +MyCompany +MyCompany's +myContainer +myContainerImage +mycorp +myCustomGateway +myCustomPack +myCustomPack +myCustomVolume mydb myenv myfile -myrg -mysample -myworkspace +myGroup +myGroup +myregistry +myResourceGroup +myResourceGroup +myrg +mysample +mySecret +mySecretStore +MySql +myStorageVolume +mySubscriptionId +myworkspace myworkspace namespace namespaces +natively +NAV nav navbar +newAWSConfig newtab +NFS +NGINX +nginx +NGroup +NGroups +nGroups +nGroups +ngroups +Nithya +nithya +nithyatsu +NMNZE +NODEAPP +NodeJS +nodeSelector noncloud +NoSchedule +NoSQL +Nowak npm +npmjs npmrc npx +ns +NSGs +nSQI +OAI +oas +OAuth +oauth objectname +Observability +observability +OCI +oci +OIDC +oidc oidcIssuer -org's -orgs +Okta +onboarded +Onboarding +onboarding +OpenAI openapi +OpenAPI +OpenAPI +openAPI +openAPIV +OpenID +openssl +OpenTelemetry +operationStatuses +ORAS +oras +orchestrator +orchestrators +orgs +org's +os +OSS +osType +otel +OTEL +OutputResources +OUTRESOURCE +OUTVALUES +overconsume +OwnedResource +OwnerReferences pageinfo +Papercut +parallelizable +parallelized param -params parametrization -parallelizable +PARAMS +params +ParseResource +parsers +PascalCased passthrough +PATs +pdf +pdfs Peirone pem +pemCertificate performant periodSeconds +persistentVolume +PersistentVolumeClaims +persistentVolumes +PersistentVolumes pfx +plaidDescription +plaidName +plaidQueue +plaidResource +plainHttp +plaintext +planeName +platformOptions +pluggable pnpm pnpm's pnpmVersion +POC +POC +PodSpec +podSpec +polymorphism +Porowski POSIX postCreateCommand +PostForm +Postgres +postgresclient +postgreSQL +postgresql postinstall Postinstall +PowerShell powershell +Pre pre +preconfigure preconfigured +predefine +preflight +Preflight +preloaded +prem +prerelease +prevState +Pri +primaryidentifier +primaryIdentifier +PrimaryIdentifier privatekey +privateKeySecretRef privateprevie privatepreview +projectcontour +ProjectRadius +prometheus +protobuf +prototyped providerConfig -publickey +ProviderSecret +provisioningState +proxying +PRs +pubkey publicEndpointOverride +publicEndpointOverride +publickey +PubSub pubsub +pubSubBrokers +Pulumi +PVCs +PVs px +pyspelling +Pyspelling +PYTHONAPP +QEMU +Quickstart quickstart +Quickstarts quickstarts -rabbitMQMessageQueues +RabbitMQ rabbitmq +rabbitMQMessageQueues +rabbitMQQueues radapp +radification +radified +Radify radiuspublic +Rahim +Raj +RBAC rbac +RDBMS +RDBMS'es +reactively +readinessProbe +readme +readmeio READMEs +readOnly +readonly +rebalancing +recipeConfig +RecipeData +RecipeDriver +RecipeEngine +RecipeInformation +recipeKind +recipeLocation +recipepack +recipepack +recipepacks +recipePacks +recipepacks +recipeParameters +RecipeSecretIds +RecipeSecrets +reconcilation +reconcilations +reconciler +Reconcilers +reconcilers recurse -rediscaches -readinessProbe redis +rediscaches redisCaches redoc +refreshInterval +RefreshToken +reimplement +reinstallation +reinstallations +rekey +releaseable +remoteRef +renderer +renderers replacePrefix +replicaset +replicasets repo +repos reproducibility +requery +Requeue +Reshma +reshrahim +ResourceDeploymentClient +resourcegroup resourceGroupName +resourceGroups +resourcegroups resourceId -resourcegroup +resourceID +resourceproviders +resourceProvisioning +resourceType +resourceTypes +RESTful +resubmission +reusability +reusability +reviewable +rfc +rg +roadmap +roadmap +roleARN +roleassignments +RoleBinding +roleRef +rolesdefinitions +Rollout rollout +Rollouts +rollouts +rootScope +roundtrips rp +rp +RPC +rpc +RPs +RP's +RRT +RRTs +runnable runtime runtimes -scalable +sa +SaaS +SBOM +SBOMs scalability -schemas +scalable +scalers +schemas +schema's +scriptable +SDK +sdk +SDKs +SecOps +SecretConfig +secretId +secretKey +secretLoader +SecretLoader +secretName +SecretProviderClass +secretRef +SecretReference +SecretsManager +secretsStores secretstore +SecretStore +secretStore +SecretStoreIds +secretStoreRef secretstores secretStores +SemVer +sensitiveApp +serializer serverless serverless +ServiceAccount +serviceaccount +serviceaccount +serviceAccountRef servicebus serviceName +setenv +severities +SHA +sha sharded shortcode shortcodes shortname +Shruthi +si +sigs +sk +SKU +sku +skuName +SKUs +SMS +SMS +SMSx +SMTP +SNI +SNS +Sonatype SoTrx spanId specificed speckit spf +SQL sql sqlDatabases +sqlite +SQLServer +SQS +SQSDeveloperGuide +src +SRE +SREs +SRG ss +SSL sslpassthrough sslPassthrough +stateful +StatefulSet statefulset +StatefulSets +STATESTORE statestore statestore +stateStores +StaticCredential +StatusCode +stdEnv +stderr stdout stgSuffixes -submodules +stringified +struct +STS +stscreds +subcommands +subcomponents +subdirectories +subdirectory submodule Submodule -subdirectory -subdirectories -Symlinked -src +submodules +Subnet subnet +SubnetGroup +Subnets subnets +suboptimal +Subramanian subscriptionID -subscriptionName subscriptionid +subscriptionId +subscriptionName sudo +superbeeny +svc +svcA +svcB +Swappable +symlink +Symlinked tablestorage +TaskDefinition +taskDefinition +TBD +TCP +tcpreplay +TCPRoute +TCPRoutes +templateKind +templatePath +templateVersion +TemplateVersion templating +tenantId +Tencent +Terraform +Terraform +terraform +terraformBackend +terraformBackend +TerraformConfig +terraformrc +Terraform's +TerraformSettings +testability +tf +TF th +throughs +timeoutPolicy +Timocin +TLS +tls +tlsCert +tlsGateway +TLSRoute +tlsSecret +tlsServiceContainerRoute tlstermination +tlsValue toc +ToCs todo +TokenExpirationSeconds +TokenExpirationSeconds +tolerations +toml +toolchains +toolset +toolsets +touchpoints traceId +trackedBy +tradeoff +tradeoffs +Traefik +transactional +Tsai +TTL +Twilio +Twilio +twilio +TypeScript +typespec +TypeSpec ubuntu -ui +UCP ucp +UCP +UCPBaseParameters +UCPD +UCP's +UDP +UDPRoute +UDT +UDT +UDTs +UDTs +UI +ui uncompiled +underverified unencrypted unmanaged +unopinionated +unregister +unregistering +Unregistration +unregistration +untrusted +untyped +unvalidated +UpdateResource +upgradeable +upmerge +upmerges +upsert +upserts +URI +uri +URIs url +usecase +userAssigned +userAssignedIdentities userguide utf +UTs +UX +validator +Validators +valueFrom +vaultUrl +VersionCompatibilityCheck +Vinaya +vinayada +virtualhost vis +vishwahiremat +Vishwanath +VMs +vNext +VPC +vpc +vpc +VSCode vscode +VSIX vsix +walkthrough webapp +webhook +webhook +webhooks webpage +webservice +webService +webServiceContainer westus -wget westus2 +wget wi +willdavsmith +willtsai +Winget workingDir -workspaceTypes +WorkloadIdentity workspaces +workspace's +workspaceTypes +workstream worktree Worktree worktrees Worktrees -walkthrough +WSL +WVKgHularsO +www +XRD +XRDs +xxxx yaml +Yetkin yml -zsh -daemonset -fluentd -minikube -Observability -Grafana -grafana -analytics -publicEndpointOverride -rp +youngbupark +YourGitHubUserName +youtu +ytimocin +Zach +zachcasper Zipkin -observability -Jaeger -jaeger -svc zipkin -upmerge -upmerges -approver -toml -templateKind -templatePath -categorizeby -jargons -mins -resourceProvisioning -ServiceAccount -apiVersion -ClusterRole -apiGroups -ClusterRoleBinding -roleRef -dropdown -apiGroup -prometheus -valueFrom -tls -minimumProtocolVersion -certificateFrom -preloaded -SRG -ePMKNy -gg -kubernetesMetadata -daprSidecar -manualScaling -YourGitHubUserName -youngbupark -vNext -codebases -datastores -armrpc -ARM -ARM's -RPs -Etag -OpenAPI -RPC -Validators -validator -proxying -operationStatuses -etag -gRPC -idl -protobuf -HashiCorp -ISRG -GCP -SecretStore -secretStore -ACMEv -ALPN -CRD -CSR -Pri -OpenAPI -FQDN -fqdn -tlsGateway -tlsSecret -tlsServiceContainerRoute -SecretsManager -resourceGroups -crt -upserts -tlsValue -rootScope -listSecrets -pemCertificate -HTTPProxy -privateKeySecretRef -commonName -dnsNames -issuerRef -letsencrypt -secretName -projectcontour -virtualhost -AzurePublicCloud -hostedZoneName -managedIdentity -docRadAppDevTLS -IAMs -cdf -sa -xxxx -WorkloadIdentity -authType -azurekv -serviceAccountRef -vaultUrl -ExternalSecret -refreshInterval -secretStoreRef -creationPolicy -KV -remoteRef -secretKey -metadataPolicy -pubkey -provisioningState -ACI -ISPs -rpc -azureDNS -clientID -tlsCert -CNAMEd -AcMEv -approvers -readme -contoso -Terraform -terraform -CADL -stringified -Terraform's -OSS -SemVer -Misconfiguration -misconfiguration -unregister -tf -underverified -ORAS -Karishma -Chawla -kachawla -orchestrator -RecipeDriver -RecipeEngine -www -BaseOptions -ExecuteOptions -struct -prevState -GarbageCollectResources -Damle -Vinaya -vinayada -idempotency -readonly -Pulumi -stateful -CloudFormation -TF -CidrBlock -mapsTo -primaryidentifier -primaryIdentifier -PrimaryIdentifier -rg -vpc -resourceID -OwnedResource -trackedBy -CreateResource -GetResource -UpdateResource -vpc -requery -backendRoute -ctnr -frontendContainer -frontendRoute -gtwy -healthz -httpGet -magpieimage -applicationName -UX -ApplicationGraph -ApplicationGraphResponse -ApplicationGraphConnection -ApplicationResource -ArmResourceActionSync -UCPBaseParameters -getGraph -UTs -E2E -backendContainer -gatewayUrl -ApplicationGraphOutputResource -ApplicationGraphResource -enum -Nithya -Subramanian -nithyatsu -Hiremath -Vishwanath -vishwahiremat -guid -prem -OutputResources -ParseResource -azurerm -hashicorp -plainHttp -typespec -myregistry -BicepRecipeProperties -oras -facto -datamodel -ytimocin -Yetkin -Timocin -templateVersion -TemplateVersion -RecipeInformation -RecipeData -CreateOrUpdateEnvironment -parsers -Shruthi -Kumar -sk -willdavsmith -IdP -AzWI -webhook -IRSA -Entra -ClientSecret -POC -scriptable -subcommands -CrashLoopBackOff -ErrImagePull -ImagePullBackOff -cpu -replicaset -replicasets -reactively -IsControlledBy -OwnerReferences -boolean -Nowak -ContainerApps -ECS -toolchains -Onboarding -catalogued -onboarded -interop -SDK -autorest -backoff -finalizers -finalizer -renderer -Rollouts -reconciler -webhooks -digestable -prototyped -webhook -onboarding -daprrp -recipeConfig -DevOps -Bitbucket -Gitlab -lakshmimsft -terraformrc -DigitalOcean -setenv -env: -Convertor -DataModel -PRs -TypeSpec -TypeScript -TerraformConfig -envVariables -EnvironmentVariables -amongst -ProviderSecret -SecretReference -bicepConfig -ECR -ecr -basicAuthentication -acr -ghcr -loadSecrets -getMetadata -FindSecretIDs -secretLoader -clientId -DefaultClient -PostForm -RefreshToken -StaticCredential -formData -jsonResponse -oauth -formData -awsIRSA -azureFederatedIdentity -basicAuthentication -tenantId -hostable -BYO -SNS -ApplicationsRP -otel -OTEL -CockroachDB -MySql -Postgres -etcd -JetStream -frontloaded -crd -tradeoffs -RDBMS -RDBMS'es -intra -mTLS -transactional -roundtrips -reimplement -keyspace -upsert -TTL -IRSA -Entra -radified -OpenID -multitenancy -roleARN -AWSCredentialProvider -AssumeRole -AssumeRoleProvider -STS -assumeRoleProviders -stscreds -AWSCredential -AWSCredentialProvider -ctx -func -newAWSConfig -nithya -planeName -POC -TokenExpirationSeconds -amazonaws -serviceaccount -oidc -assumeRoleProvider -TokenExpirationSeconds -amazonaws -serviceaccount -arns -Tsai -willtsai -ArgoCD -GitOps -repos -SRE -SREs -toolset -toolsets -generalizable -fluxcd -Kustomize -kustomize -usecase -gitops -predefine -KRM -secretsStores -DriverWithSecrets -FindSecretIds -SecretStoreIds -LoadSecrets -SecretLoader -ConfigStructure -RecipeSecretIds -RecipeSecrets -lakshmimsft -Radify -DeploymentTemplate -DeploymentResource -superbeeny -Beenham -secretRef -sdk -dataflow -dataflows -UCP -UCP's -CEL -masse -touchpoints -unvalidated -parallelized -UDT -UDTs -hardcoded -RP's -Unregistration -unregistering -workstream -tradeoff -contrib -carte -customizable -implementers -azureWorkloadIdentity -untrusted -mitigations -Mitigations -Misconfigurations -MitM -DoS -Auditability -failover -checksums -CustomResourceDefinitions -UCPD -interactor -Reconcilers -reconcilers -reconcilation -reconcilations -Kubebuilder -crypto -cryptographically -SHA -sha -rfc -configs -sqlite -ApplicationsCore -Rahim -Reshma -reshrahim -untyped -benefitted -Raj -SKU -SKUs -CRD -XRD -XRDs -CRDs -Crossplane -intellisense -postgreSQL -autocompletion -integrators -IntelliSense -radification -openAPI -discoverable -os -plaidDescription -plaidName -plaidQueue -locational -unregistration -rollouts -UDT -UDTs -encodings -invariants -Mycompany -plaidResource -resourceTypes -Casper -Zach -zachcasper -Okta -DBAs -RoleBinding -MyCompany -MyCompany's -Deployer -deployers -DBA -ISVs -DBAs -SecretConfig -deployTo -deployer -resourcegroups -resourceproviders -roleassignments -rolesdefinitions -AuthN -AuthZ -apiserver -ETags -ETag -cryptographic -Cryptographic -Dockerfile -AnonymousCredential -ConfigMaps -SecOps -kube -workspace's -Authorizer -ISV -reusability -recipepacks -recipepack -cd -myResourceGroup -myCustomPack -myGroup -Dependabot -dependabot -engs -aspirationally -memcached -roadmap -VMs -cleartext -Twilio -authenticator -ACA -CloudRun -scalers -Datadog -OpenTelemetry -LLM -SBOMs -SMS -PascalCased -IDEs -camelCased -SMS -SMSx -idleConnection -timeoutPolicy -httpproxy -apis -backendrequest -sigs -Aditi -Twilio -PATs -runnable -debuggable -DSL -Helly -GitRepository -bicepconfig -Jira -webservice -Papercut -manualResourceProvisioning -manualProvisioning -webService -jira -CoPilot -balancer -NGINX -webServiceContainer -twilio -NGroups -NGroup -balancers -renderers -ConfigLoader -ACICompute -KubernetesCompute -ACI -aci -daprextension -kubernetesMetadata -kubernetesmetadata -manualscale -NSGs -IPs -KeyVault -pluggable -RESTful -upgradeable -pyspelling -Pyspelling -CNCF -CloudRun -Fargate -autoscaling -loadBalancer -ACA -nGroups -rebalancing -datacenters -interruptible -Genericize -unopinionated -roadmap -preconfigure -suboptimal -PodSpec -natively -tolerations -orchestrators -Dq -NMNZE -WVKgHularsO -nGroups -nSQI -si -youtu -APIReference -AmazonECS -developerguide -ecs -ngroups -pdf -pdfs -Knative -genericized -gapped -npmjs -Sonatype -amd -darwin -Homebrew -Winget -howto -AzureDevOps -ns -deletable -cardinality -Istio -Flux -reinstallation -reinstallations -gapped -helmclient -contourclient -inmemory -postgresclient -PVs -AcquireLock -postgresql -preflight -Preflight -severities -PersistentVolumes -VersionCompatibilityCheck -ClusterResourceCheck -ControlPlaneHealthCheck -CustomConfigValidationCheck -dir -rekey -etcd's -TerraformSettings -AzureDevops -backends -Alibaba -Tencent -fluentbit -GPUs -impactful -initContainer -autoscaler -NFS -TaskDefinition -Balancer -Fargate -aci -defaultCpu -defaultMemoryInGB -defaultSku -gz -URI -compute's -nginx -confidentialCompute -connectionStrings -mycorp -mycache -osType -sku -RRT -RRTs -OpenAI -ContainerGroupProfile -freeform -AppCore -recipePacks -uri -containerGroupProfile -allowPlatformOptions -mySubscriptionId -confi -platformOptions -NoSchedule -podSpec -taskDefinition -myContainer -myContainerImage -mySecretStore -throughs -enablement -persistentVolume -myCustomVolume -myCustomGateway -Traefik -bicepparam -computeRecipePack -dataRecipePack -EBS -environmentVariables -memoryInGB -mySecret -myStorageVolume -oci -recipeKind -recipeLocation -recipeParameters -resourceType -sensitiveApp -skuName -stdEnv -userAssigned -userAssignedIdentities -subscriptionId -pubSubBrokers -rabbitMQQueues -bicepSettings -terraformBackend -bicepAuthentication -eBPF -httpRouteConfig -backendRef -TCPRoutes -HTTPRoute -HTTPRoute -TCPRoute -TLSRoute -UDPRoute -svcA -svcB -ClusterIP -kubeproxy -httpconf -DML -bicepSettings -terraformBackend -bicepAuthentication -filesystem -apiKey -discoverability -incentivize -NoSQL -configurationStores -stateStores -ISV -decrypt -plaintext -decrypts -resubmission -ciphertext -deserialization -Requeue -reusability -recipepacks -recipepack -cd -myResourceGroup -myCustomPack -myGroup -Dependabot -dependabot -eng -AzureRM -BasicAuth -reviewable -serializer -deduplicated -behaviour -stderr -symlink +zsh diff --git a/README.md b/README.md index 8a6990de..31f01949 100644 --- a/README.md +++ b/README.md @@ -1,5 +1,12 @@ # Design notes +--- + +> [!WARNING] +> This repository has been moved to the main [Radius repository](https://github.com/radius-project/radius) and is no longer actively maintained. + +--- + This `design-notes` repository contains design proposals, enhancements, and architectural decisions for Radius. It provides a consistent and controlled path to record changes and developments, ensuring clarity and transparency for all stakeholders in the Radius community. Design notes are used for evaluating the design of **planned** changes and additions to Radius. Do not use this repository for feature requests - please create an issue on the [main Radius repository](https://github.com/radius-project) instead. We create documents in this repo to describe **why** and **how** to accomplish something once we have agreement that it is appropriate for the project. diff --git a/tools/2026-03-goreleaser-release-lifecycle.md b/tools/2026-03-goreleaser-release-lifecycle.md index fd4db34f..eeecc382 100644 --- a/tools/2026-03-goreleaser-release-lifecycle.md +++ b/tools/2026-03-goreleaser-release-lifecycle.md @@ -1,6 +1,6 @@ # GoReleaser Release Lifecycle -* **Author**: Dariusz Porowski (draft) +- **Author**: Dariusz Porowski ## Overview @@ -12,12 +12,12 @@ This approach simplifies procedures, reduces maintenance cost, removes custom wo ## Terms and definitions -* **GoReleaser**: A release automation tool for Go projects that can build binaries, package archives, publish container images, create GitHub Releases, and generate changelogs from git metadata. -* **Release lifecycle**: The end-to-end process for producing and publishing Radius binaries, container images, GitHub Releases, release notes, and downstream coordination. -* **Release channel**: The major and minor stream for a Radius release, such as `0.56`, used to group compatible artifacts and release branches. -* **Snapshot build**: A non-final build used for pull requests and branch validation, typically without publishing an official GitHub Release. -* **Post-release coordination**: Follow-on automation that should remain outside the main GoReleaser configuration, such as tagging sibling repositories, dispatching external workflows, and updating documentation-only metadata. -* **Non-Go artifact**: A release output not directly produced by the main Go module builds, such as the Bicep image, Helm chart, or externally published deployment-engine assets. +- **GoReleaser**: A release automation tool for Go projects that can build binaries, package archives, publish container images, create GitHub Releases, and generate changelogs from git metadata. +- **Release lifecycle**: The end-to-end process for producing and publishing Radius binaries, container images, GitHub Releases, release notes, and downstream coordination. +- **Release channel**: The major and minor stream for a Radius release, such as `0.56`, used to group compatible artifacts and release branches. +- **Snapshot build**: A non-final build used for pull requests and branch validation, typically without publishing an official GitHub Release. +- **Post-release coordination**: Follow-on automation that should remain outside the main GoReleaser configuration, such as tagging sibling repositories, dispatching external workflows, and updating documentation-only metadata. +- **Non-Go artifact**: A release output not directly produced by the main Go module builds, such as the Bicep image, Helm chart, or externally published deployment-engine assets. ## Objectives @@ -25,21 +25,21 @@ This approach simplifies procedures, reduces maintenance cost, removes custom wo ### Goals -* Make GoReleaser the single source of truth for Radius releaseable Go artifacts. -* Replace the current hand-rolled Makefile, shell, and Python release logic with declarative release configuration where practical. -* Reduce the current workflow complexity, including the existing multi-step manual release procedure and the duplication between local build logic and CI/CD workflows. -* Preserve existing user-facing release outputs: CLI archives, checksums, multi-arch server images, GitHub Releases, and release-channel semantics. -* Keep multi-repository coordination and non-Go outputs as thin workflows around the core GoReleaser release rather than embedding that logic into Make or ad hoc scripts. -* Establish a release foundation that can be extended with signing, SBOMs, attestations, richer changelog handling, and stronger version metadata without another round of custom automation. -* Encourage structured changelog input by standardizing on conventional-commit style prefixes, preferably enforced through PR titles and commit conventions. +- Make GoReleaser the single source of truth for Radius releaseable Go artifacts. +- Replace the current hand-rolled Makefile, shell, and Python release logic with declarative release configuration where practical. +- Reduce the current workflow complexity, including the existing multi-step manual release procedure and the duplication between local build logic and CI/CD workflows. +- Preserve existing user-facing release outputs: CLI archives, checksums, multi-arch server images, GitHub Releases, and release-channel semantics. +- Keep multi-repository coordination and non-Go outputs as thin workflows around the core GoReleaser release rather than embedding that logic into Make or ad hoc scripts. +- Establish a release foundation that can be extended with signing, SBOMs, attestations, richer changelog handling, and stronger version metadata without another round of custom automation. +- Encourage structured changelog input by standardizing on conventional-commit style prefixes, preferably enforced through PR titles and commit conventions. ### Non goals -* Rewriting every existing release-adjacent workflow in the first iteration. The scope is the core Radius build and release path. -* Moving all non-Go assets into GoReleaser immediately. The Helm chart, Bicep image, deployment-engine publication, and sibling repository dispatch remain separate where they are operationally distinct. -* Changing public Radius APIs or the end-user install experience as part of this design. -* Solving every supply-chain requirement in the first migration. This design enables later adoption of code signing, SBOMs, and attestations, but it does not require all of them on day one. -* Changing the release-branch model. The existing `release/x.y` branching approach remains in place. +- Rewriting every existing release-adjacent workflow in the first iteration. The scope is the core Radius build and release path. +- Moving all non-Go assets into GoReleaser immediately. The Helm chart, Bicep image, deployment-engine publication, and sibling repository dispatch remain separate where they are operationally distinct. +- Changing public Radius APIs or the end-user install experience as part of this design. +- Solving every supply-chain requirement in the first migration. This design enables later adoption of code signing, SBOMs, and attestations, but it does not require all of them on day one. +- Changing the release-branch model. The existing `release/x.y` branching approach remains in place. ### User scenarios (optional) @@ -137,12 +137,12 @@ flowchart TD The current release path has several structural problems: -* Around 600 lines of Make includes are dedicated to concerns that are standard release-tool behavior: compilation, version propagation, archive layout, Docker image handling, and artifact management. -* Version computation relies on a custom Python parser and multiple shell helpers. -* `versions.yaml` currently acts as a release trigger, which adds indirection and turns a documentation file into an automation control plane. -* The release process is operationally complex, involving many manual steps, multi-repository coordination, and duplicated logic between CI and local development. -* Changelog generation is inconsistent between RC and final releases. -* The existing workflow structure uses multiple matrix and helper jobs where one release-oriented tool can express the same intent more directly. +- Around 600 lines of Make includes are dedicated to concerns that are standard release-tool behavior: compilation, version propagation, archive layout, Docker image handling, and artifact management. +- Version computation relies on a custom Python parser and multiple shell helpers. +- `versions.yaml` currently acts as a release trigger, which adds indirection and turns a documentation file into an automation control plane. +- The release process is operationally complex, involving many manual steps, multi-repository coordination, and duplicated logic between CI and local development. +- Changelog generation is inconsistent between RC and final releases. +- The existing workflow structure uses multiple matrix and helper jobs where one release-oriented tool can express the same intent more directly. These issues are not isolated bugs. They are symptoms of a release system whose complexity now exceeds the complexity of the product changes it is meant to ship. @@ -150,47 +150,47 @@ These issues are not isolated bugs. They are symptoms of a release system whose ##### Advantages of Option 1 -* No migration cost in the short term. -* No need to re-validate artifact names, image tags, or release job behavior. -* Existing release engineers already know the process. +- No migration cost in the short term. +- No need to re-validate artifact names, image tags, or release job behavior. +- Existing release engineers already know the process. ##### Disadvantages of Option 1 -* Complexity continues to grow in Make, shell, Python, and workflow YAML. -* Release improvements remain costly because every enhancement requires more bespoke plumbing. -* The current release procedure remains difficult to debug, review, and explain. -* Supply-chain enhancements such as signing, SBOMs, and attestations continue to require custom integration work. +- Complexity continues to grow in Make, shell, Python, and workflow YAML. +- Release improvements remain costly because every enhancement requires more bespoke plumbing. +- The current release procedure remains difficult to debug, review, and explain. +- Supply-chain enhancements such as signing, SBOMs, and attestations continue to require custom integration work. #### Option 2: Use GoReleaser only for binaries and keep custom image and release logic ##### Advantages of Option 2 -* Reduces some Make complexity without forcing a full migration. -* Lowers risk by limiting the blast radius of the initial change. -* Allows quick adoption for CLI artifact generation. +- Reduces some Make complexity without forcing a full migration. +- Lowers risk by limiting the blast radius of the initial change. +- Allows quick adoption for CLI artifact generation. ##### Disadvantages of Option 2 -* Leaves the largest workflow complexity in place because image publication and GitHub Release creation remain custom. -* Splits the release source of truth between GoReleaser and GitHub workflow YAML. -* Delays many of the maintenance and supply-chain benefits that justify the migration. +- Leaves the largest workflow complexity in place because image publication and GitHub Release creation remain custom. +- Splits the release source of truth between GoReleaser and GitHub workflow YAML. +- Delays many of the maintenance and supply-chain benefits that justify the migration. #### Option 3: Use GoReleaser as the core release source of truth and keep only lightweight post-release workflows ##### Advantages of Option 3 -* Produces the biggest simplification in procedures and maintenance. -* Moves the common release concerns into a single declarative tool that many Go projects already understand. -* Removes duplicated logic across Make, Python, shell scripts, and workflow jobs. -* Improves local testability because the same release configuration can be run in snapshot mode outside official tagged releases. -* Creates a natural path for adding signing, SBOM, attestation, and changelog improvements. -* Better aligns Radius with common release practices used by open-source Go projects and CNCF-adjacent tooling. +- Produces the biggest simplification in procedures and maintenance. +- Moves the common release concerns into a single declarative tool that many Go projects already understand. +- Removes duplicated logic across Make, Python, shell scripts, and workflow jobs. +- Improves local testability because the same release configuration can be run in snapshot mode outside official tagged releases. +- Creates a natural path for adding signing, SBOM, attestation, and changelog improvements. +- Better aligns Radius with common release practices used by open-source Go projects and CNCF-adjacent tooling. ##### Disadvantages of Option 3 -* Requires careful migration to preserve artifact naming, base-image behavior, and downstream workflow expectations. -* Some assets still remain outside GoReleaser, so the overall release system is simplified rather than fully centralized. -* The team must learn and review one new release configuration format. +- Requires careful migration to preserve artifact naming, base-image behavior, and downstream workflow expectations. +- Some assets still remain outside GoReleaser, so the overall release system is simplified rather than fully centralized. +- The team must learn and review one new release configuration format. #### Proposed Option @@ -204,12 +204,12 @@ The proposed design has the following main parts. The repository adds a single `.goreleaser.yaml` file that defines: -* Six primary Go builds from the main module: `rad`, `ucpd`, `applications-rp`, `dynamic-rp`, `controller`, and `pre-upgrade`. -* CLI archive creation for `rad` with Windows ZIP output and tarballs for other operating systems. -* Raw binary outputs for server binaries that are intended for container packaging. -* Checksum generation. -* GitHub Release creation. -* Changelog grouping and filtering. +- Six primary Go builds from the main module: `rad`, `ucpd`, `applications-rp`, `dynamic-rp`, `controller`, and `pre-upgrade`. +- CLI archive creation for `rad` with Windows ZIP output and tarballs for other operating systems. +- Raw binary outputs for server binaries that are intended for container packaging. +- Checksum generation. +- GitHub Release creation. +- Changelog grouping and filtering. `docgen` remains a local or developer build concern rather than a published artifact. Test binaries with separate Go modules remain outside the main configuration, either in independent configs or separate workflows. @@ -217,11 +217,11 @@ The repository adds a single `.goreleaser.yaml` file that defines: GoReleaser builds and publishes the production multi-architecture server images for: -* `ucpd` -* `applications-rp` -* `dynamic-rp` -* `controller` -* `pre-upgrade` +- `ucpd` +- `applications-rp` +- `dynamic-rp` +- `controller` +- `pre-upgrade` Each image retains its current base-image requirements. Separate `Dockerfile.goreleaser` files are used where necessary to align with GoReleaser's build context while preserving the current runtime characteristics. @@ -245,9 +245,9 @@ GoReleaser generates a changelog from git history and can group entries into sec The recommended enforcement path is: -* Require conventional-commit style PR titles for squash-merged changes. -* Encourage the same prefixes in commits when practical. -* Keep changelog fallback groups so imperfect commit hygiene does not block releases. +- Require conventional-commit style PR titles for squash-merged changes. +- Encourage the same prefixes in commits when practical. +- Keep changelog fallback groups so imperfect commit hygiene does not block releases. Release notes in the docs tree can still be attached or referenced from the GitHub Release, but the release creation path becomes a single code path for both RC and final releases. @@ -255,11 +255,11 @@ Release notes in the docs tree can still be attached or referenced from the GitH Some actions should remain outside GoReleaser because they are not native release outputs of the main Go module. These include: -* Tagging sibling repositories such as `recipes` and `dashboard`. -* Dispatching external publication workflows, including deployment-engine image publication. -* Triggering docs and samples release or validation workflows. -* Updating `versions.yaml` via an automated pull request after a successful release. -* Publishing the Helm chart and Bicep image where separate packaging logic is still preferable. +- Tagging sibling repositories such as `recipes` and `dashboard`. +- Dispatching external publication workflows, including deployment-engine image publication. +- Triggering docs and samples release or validation workflows. +- Updating `versions.yaml` via an automated pull request after a successful release. +- Publishing the Helm chart and Bicep image where separate packaging logic is still preferable. This keeps the orchestration model clean: GoReleaser produces the core release, and the coordination workflow reacts to the published release. @@ -267,11 +267,11 @@ This keeps the orchestration model clean: GoReleaser produces the core release, One reason to prefer GoReleaser over more custom scripts is not only current simplification but future extensibility. A standard release tool makes it easier to add: -* Artifact signing. -* Container image signing. -* SBOM generation. -* Provenance and attestation publication. -* Richer OCI labels and metadata. +- Artifact signing. +- Container image signing. +- SBOM generation. +- Provenance and attestation publication. +- Richer OCI labels and metadata. This design does not require all of these on day one, but it intentionally creates a release structure where adding them is incremental rather than architectural. @@ -297,17 +297,17 @@ There is an internal workflow-experience change for maintainers: a helper workfl The main build workflow is simplified into clear operating modes: -* Tag push: run GoReleaser in full release mode. -* Pull request or branch push: run GoReleaser in snapshot mode. -* Main branch push: optionally publish `latest` images and edge-oriented outputs. +- Tag push: run GoReleaser in full release mode. +- Pull request or branch push: run GoReleaser in snapshot mode. +- Main branch push: optionally publish `latest` images and edge-oriented outputs. The workflow is responsible for environment preparation only: -* Checking out the repository with full git history. -* Setting up Go, QEMU, Buildx, and registry credentials. -* Computing release metadata. -* Invoking GoReleaser. -* Uploading snapshot artifacts where later jobs need them. +- Checking out the repository with full git history. +- Setting up Go, QEMU, Buildx, and registry credentials. +- Computing release metadata. +- Invoking GoReleaser. +- Uploading snapshot artifacts where later jobs need them. This is consistent with the design principle that GitHub workflows should primarily handle setup, identity, and orchestration rather than encode the release logic itself. @@ -315,12 +315,12 @@ This is consistent with the design principle that GitHub workflows should primar The GoReleaser configuration becomes the main declarative specification for: -* Build matrix. -* Archive naming. -* Checksums. -* Docker image definitions and manifest lists. -* GitHub Release metadata. -* Changelog grouping. +- Build matrix. +- Archive naming. +- Checksums. +- Docker image definitions and manifest lists. +- GitHub Release metadata. +- Changelog grouping. Version metadata previously computed in Python and Make is injected through environment variables and git-derived fields already available to GoReleaser. @@ -328,10 +328,10 @@ Version metadata previously computed in Python and Make is injected through envi Dedicated GoReleaser Dockerfiles should be created for components whose current Dockerfiles assume the existing Make dist layout. These Dockerfiles must preserve runtime parity with today's images, including: -* Base image family. -* Required packages such as CA certificates, git, or openssl. -* Non-root user behavior. -* Extra copied files, especially the built-in UCP manifests. +- Base image family. +- Required packages such as CA certificates, git, or openssl. +- Non-root user behavior. +- Extra copied files, especially the built-in UCP manifests. Preserving runtime parity is a migration requirement, not an optional cleanup item. @@ -345,23 +345,23 @@ This is a cleaner separation of concerns and reduces failure modes caused by mix The existing release documentation in the main Radius repository should be updated after implementation to reflect the new process. The long manual checklist can be reduced to: -* prepare release branch if needed, -* create or push the release tag, -* monitor the build and release workflow, -* monitor the post-release coordination workflow, -* run release verification, -* handle any downstream approvals that remain intentionally separate. +- prepare release branch if needed, +- create or push the release tag, +- monitor the build and release workflow, +- monitor the post-release coordination workflow, +- run release verification, +- handle any downstream approvals that remain intentionally separate. ### Error Handling The new design should treat the following failure modes explicitly: -* Invalid version tag: the helper workflow validates semantic version format before tag creation. -* Missing git history: release jobs must use full fetch depth because GoReleaser depends on tag and commit metadata. -* Image publication failure for a single architecture: the release job fails fast and does not silently publish partial manifests. -* Changelog classification gaps: unclassified entries fall into a default group rather than failing the release. -* Post-release coordination failure: the release remains published, but follow-on jobs surface actionable failures with clear workflow summaries. -* External-dispatch failure: downstream repository dispatch and monitoring steps report explicit failure rather than relying on manual polling. +- Invalid version tag: the helper workflow validates semantic version format before tag creation. +- Missing git history: release jobs must use full fetch depth because GoReleaser depends on tag and commit metadata. +- Image publication failure for a single architecture: the release job fails fast and does not silently publish partial manifests. +- Changelog classification gaps: unclassified entries fall into a default group rather than failing the release. +- Post-release coordination failure: the release remains published, but follow-on jobs surface actionable failures with clear workflow summaries. +- External-dispatch failure: downstream repository dispatch and monitoring steps report explicit failure rather than relying on manual polling. The workflow summary should provide a concise status report so release engineers can see which stage failed without reading every job log in detail. @@ -369,14 +369,14 @@ The workflow summary should provide a concise status report so release engineers The migration should be validated in phases. -* Compare current and proposed outputs for at least one RC-style build and one final release candidate in a dry-run or staging branch. -* Run `goreleaser check` and `goreleaser release --snapshot --clean` locally and in CI to validate configuration, archive layout, and image definitions. -* Verify that release metadata injected into binaries still reports the expected version, channel, commit, and chart version fields. -* Verify that published container images preserve runtime behavior, base-image assumptions, and required files. -* Validate that the GitHub Release contains the expected archives, checksums, notes, and prerelease/final classification. -* Validate that main-branch snapshot flows still provide the artifacts required by functional tests and edge publication. -* Validate that post-release workflows still tag sibling repositories, dispatch external publication, and update `versions.yaml` as expected. -* Run the existing release verification workflow against a migrated RC and final release before deprecating the old process. +- Compare current and proposed outputs for at least one RC-style build and one final release candidate in a dry-run or staging branch. +- Run `goreleaser check` and `goreleaser release --snapshot --clean` locally and in CI to validate configuration, archive layout, and image definitions. +- Verify that release metadata injected into binaries still reports the expected version, channel, commit, and chart version fields. +- Verify that published container images preserve runtime behavior, base-image assumptions, and required files. +- Validate that the GitHub Release contains the expected archives, checksums, notes, and prerelease/final classification. +- Validate that main-branch snapshot flows still provide the artifacts required by functional tests and edge publication. +- Validate that post-release workflows still tag sibling repositories, dispatch external publication, and update `versions.yaml` as expected. +- Run the existing release verification workflow against a migrated RC and final release before deprecating the old process. ## Security @@ -386,11 +386,11 @@ The workflow should continue to use least-privilege GitHub permissions. Release GoReleaser adoption also creates a better foundation for future supply-chain controls. After the baseline migration, Radius should evaluate: -* artifact and container signing, -* SBOM generation, -* provenance attestations, -* stronger release metadata standards, -* removal or reduction of long-lived personal access tokens where possible. +- artifact and container signing, +- SBOM generation, +- provenance attestations, +- stronger release metadata standards, +- removal or reduction of long-lived personal access tokens where possible. No new end-user secrets, encryption models, or authentication flows are introduced by this design. @@ -400,10 +400,10 @@ The intended compatibility goal is no user-visible change to how Radius release Compatibility requirements: -* Preserve existing binary names and operating-system coverage. -* Preserve current release channel behavior for tagged releases. -* Preserve production image names and major tag conventions. -* Preserve RC versus final release semantics. +- Preserve existing binary names and operating-system coverage. +- Preserve current release channel behavior for tagged releases. +- Preserve production image names and major tag conventions. +- Preserve RC versus final release semantics. The main compatibility change is internal: release engineers will no longer use `versions.yaml` edits as the release trigger, and documentation must be updated accordingly. @@ -413,19 +413,19 @@ The primary observability surface for this design is GitHub Actions. Recommended instrumentation and diagnostics: -* Step summaries in build and coordination workflows. -* Explicit logging of computed release metadata. -* Clear GoReleaser output retention in workflow logs. -* Release-coordination logs for sibling repository tagging and downstream dispatch. -* Continued use of the existing release verification workflow as an operational validation step. +- Step summaries in build and coordination workflows. +- Explicit logging of computed release metadata. +- Clear GoReleaser output retention in workflow logs. +- Release-coordination logs for sibling repository tagging and downstream dispatch. +- Continued use of the existing release verification workflow as an operational validation step. For troubleshooting, maintainers should be able to answer these questions quickly: -* Was the tag valid and fetched correctly? -* Did GoReleaser build all expected artifacts? -* Which image architecture, if any, failed? -* Was the GitHub Release created? -* Did downstream coordination complete or fail? +- Was the tag valid and fetched correctly? +- Did GoReleaser build all expected artifacts? +- Which image architecture, if any, failed? +- Was the GitHub Release created? +- Did downstream coordination complete or fail? ## Development plan @@ -433,44 +433,44 @@ The work should be delivered in phases. ### Phase 1: Introduce GoReleaser configuration -* Add `.goreleaser.yaml` for the six production Go binaries. -* Add archive, checksum, changelog, and release configuration. -* Add GoReleaser-specific Dockerfiles where needed. +- Add `.goreleaser.yaml` for the six production Go binaries. +- Add archive, checksum, changelog, and release configuration. +- Add GoReleaser-specific Dockerfiles where needed. ### Phase 2: Migrate the main build workflow -* Replace the current custom release logic in `build.yaml` with GoReleaser release and snapshot modes. -* Preserve artifact upload points needed by tests and edge publication. -* Validate that PR and main-branch scenarios still work. +- Replace the current custom release logic in `build.yaml` with GoReleaser release and snapshot modes. +- Preserve artifact upload points needed by tests and edge publication. +- Validate that PR and main-branch scenarios still work. ### Phase 3: Add post-release coordination workflow -* Trigger sibling repository tagging, external dispatch, and downstream notifications from the published GitHub Release event. -* Demote `versions.yaml` to documentation and update it through an automated pull request. +- Trigger sibling repository tagging, external dispatch, and downstream notifications from the published GitHub Release event. +- Demote `versions.yaml` to documentation and update it through an automated pull request. ### Phase 4: Remove obsolete custom logic -* Remove obsolete Make includes and version-parsing scripts. -* Reduce release documentation to the new tag-driven process. -* Keep only developer-centric Make targets that still provide local value. +- Remove obsolete Make includes and version-parsing scripts. +- Reduce release documentation to the new tag-driven process. +- Keep only developer-centric Make targets that still provide local value. ### Phase 5: Follow-up hardening -* Standardize changelog input with conventional-commit style PR titles or commits. -* Evaluate signing, SBOM, and attestation additions. -* Revisit any remaining non-Go publication steps for future simplification. +- Standardize changelog input with conventional-commit style PR titles or commits. +- Evaluate signing, SBOM, and attestation additions. +- Revisit any remaining non-Go publication steps for future simplification. ## Open Questions -* Should the initial migration include SBOM generation, or should that remain a follow-up once the core release path is stable? -* Should conventional-commit enforcement happen on commits, PR titles, or both? -* Should the test-module binaries (`testrp`, `magpiego`) receive their own GoReleaser configuration immediately or remain on separate build logic for now? -* Should the Helm chart remain a dedicated workflow permanently, or should it later move to a more integrated release path? -* Should the Bicep image stay outside GoReleaser indefinitely because it is an externally downloaded artifact, or should it eventually adopt a related release automation path? -* Can the official release job switch from a long-lived PAT to an alternative identity model without losing required GitHub Release behavior? +- Should the initial migration include SBOM generation, or should that remain a follow-up once the core release path is stable? +- Should conventional-commit enforcement happen on commits, PR titles, or both? +- Should the test-module binaries (`testrp`, `magpiego`) receive their own GoReleaser configuration immediately or remain on separate build logic for now? +- Should the Helm chart remain a dedicated workflow permanently, or should it later move to a more integrated release path? +- Should the Bicep image stay outside GoReleaser indefinitely because it is an externally downloaded artifact, or should it eventually adopt a related release automation path? +- Can the official release job switch from a long-lived PAT to an alternative identity model without losing required GitHub Release behavior? ## Alternatives considered -* Keep the current custom release stack and optimize individual workflows. Rejected because it does not address the structural problem of duplicated and fragmented release logic. -* Use GoReleaser only for CLI archives. Rejected because it captures only a small portion of the maintenance savings and leaves image and release orchestration complexity largely unchanged. -* Move every release-related activity into GoReleaser immediately. Rejected because some cross-repository and non-Go operations are better modeled as follow-on workflows reacting to a published release. +- Keep the current custom release stack and optimize individual workflows. Rejected because it does not address the structural problem of duplicated and fragmented release logic. +- Use GoReleaser only for CLI archives. Rejected because it captures only a small portion of the maintenance savings and leaves image and release orchestration complexity largely unchanged. +- Move every release-related activity into GoReleaser immediately. Rejected because some cross-repository and non-Go operations are better modeled as follow-on workflows reacting to a published release.