-
Notifications
You must be signed in to change notification settings - Fork 90
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add TektonCD pipeline #63
Conversation
a2542f9
to
729d879
Compare
0.12.6 seems to fix the errors when running TF with Google's new workload identity.
Having all cluster pairs in one TF configuration makes hard or even impossible to have each cluster apply its own configuration during the in-cluster Tekton run. * This PR splits the tests into one subdirectory per cluster pair. * It also puts the state for each cluster pair into the respective provider's object store.
@@ -5,10 +5,9 @@ locals { | |||
|
|||
workspace_label = "${var.label_namespace}cluster_workspace" | |||
workspace = var.metadata_labels[local.workspace_label] | |||
build_path = "manifests/overlays/${var.cluster_type}/${local.workspace}" | |||
build_path = "../manifests/overlays/${var.cluster_type}/${local.workspace}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: Remember to change directory layout in quickstart too.
@@ -0,0 +1,8 @@ | |||
terraform { | |||
backend "azurerm" { | |||
resource_group_name = "terraform-kubestack-testing" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TODO: Update quickstart to also include resource_group_name
and update instructions too.
This workflow is necessary to prevent the bootstrap failing when applying the pipeline manifests before TektonCD CRDs have been created successfully. The pipeline will in any case always need the repository, host-key and in most cases a ssh private-key to access private repositories. User bootstrap worklow will most likely be: 1. local repository 2. bootstrap ops and apps clusters 3. push local repository to remote 4. link clusters to repository
I'm stopping the effort to move the automation inside each cluster using Tekton, because there is no good solution to handle potential delete/recreate or destroy scenarios from within the cluster itself. Tekton is very complex and the above limitation means it does not add enough value to justify the maintenance effort it requires. |
No description provided.