Skip to content
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

Closed
wants to merge 15 commits into from
Closed

Add TektonCD pipeline #63

wants to merge 15 commits into from

Conversation

pst
Copy link
Member

@pst pst commented Jun 27, 2019

No description provided.

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}"
Copy link
Member Author

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"
Copy link
Member Author

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
@pst
Copy link
Member Author

pst commented Dec 10, 2019

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.

@pst pst closed this Dec 10, 2019
@pst pst deleted the pipeline branch April 17, 2021 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant