rename the project to csctl (#77)

we want to rename the project to csctl given the
client tool deals with cluster stacks.

Signed-off-by: kranurag7 <[email protected]>

.github/ISSUE_TEMPLATE/bug_report.md

@@ -19,5 +19,5 @@ about: Tell us about a problem you are experiencing.
 
 **Environment:**
 
-- csmctl version: (use `csmctl version`)
+- csctl version: (use `csctl version`)
 - OS (e.g. from `/etc/os-release`): 

.github/ISSUE_TEMPLATE/feature_request.md

@@ -16,4 +16,4 @@ about: Suggest an idea for this project.
 
 **Environment:**
 
-- csmctl version: (use `kubectl version`)
+- csctl version: (use `csctl version`)

.github/renovate.json5

@@ -7,20 +7,20 @@
     ":semanticCommits",
     "helpers:pinGitHubActionDigests",
     "github>whitesource/merge-confidence:beta",
-    "github>SovereignCloudStack/csmctl//.github/renovate/commitMessage.json5",
-    "github>SovereignCloudStack/csmctl//.github/renovate/approval.json5",
-    "github>SovereignCloudStack/csmctl//.github/renovate/golang.json5",
-    "github>SovereignCloudStack/csmctl//.github/renovate/groups.json5",
-    "github>SovereignCloudStack/csmctl//.github/renovate/labels.json5",
-    "github>SovereignCloudStack/csmctl//.github/renovate/regexManagers.json5"
+    "github>SovereignCloudStack/csctl//.github/renovate/commitMessage.json5",
+    "github>SovereignCloudStack/csctl//.github/renovate/approval.json5",
+    "github>SovereignCloudStack/csctl//.github/renovate/golang.json5",
+    "github>SovereignCloudStack/csctl//.github/renovate/groups.json5",
+    "github>SovereignCloudStack/csctl//.github/renovate/labels.json5",
+    "github>SovereignCloudStack/csctl//.github/renovate/regexManagers.json5"
   ],
   platform: "github",
   baseBranches: ["main"],
   onboarding: false,
   requireConfig: "ignored",
   timezone: "Europe/Berlin",
   // repo config
-  repositories: ["SovereignCloudStack/csmctl"],
+  repositories: ["SovereignCloudStack/csctl"],
   ignorePaths: [
     "**/vendor/**",
     "**/test/**",

.github/renovate/groups.json5

@@ -3,7 +3,7 @@
     {
       description: "Update Builder Image",
       groupName: "Builder Image",
-      groupSlug: "csmctl-builder-image",
+      groupSlug: "csctl-builder-image",
       commitMessageTopic: "Builder Image group",
       matchPaths: ["images/builder/**"],
       separateMajorMinor: false,
@@ -56,10 +56,10 @@
       groupSlug: "golang-deps",
     },
     {
-      description: "disable update of csmctl builder image",
+      description: "disable update of csctl builder image",
       matchManagers: ["github-actions"],
       matchUpdateTypes: ["major", "minor", "patch"],
-      matchPackageNames: ["ghcr.io/sovereigncloudstack/csmctl-builder"],
+      matchPackageNames: ["ghcr.io/sovereigncloudstack/csctl-builder"],
       enabled: false,
     },
   ]

.github/workflows/build.yml

@@ -1,4 +1,4 @@
-name: Build csmctl binary
+name: Build csctl binary
 # yamllint disable rule:line-length
 on: # yamllint disable-line rule:truthy
   push:
@@ -19,4 +19,4 @@ jobs:
       # Load Golang cache build from GitHub
       - name: build go binary
         run: |
-          go build -o csmctl main.go
+          go build -o csctl main.go

.github/workflows/builder-image.yml

@@ -32,4 +32,4 @@ jobs:
           file: ./images/builder/Dockerfile
           context: ./images/builder
           push: true
-          tags: ghcr.io/sovereigncloudstack/csmctl-builder:0.2.0
+          tags: ghcr.io/sovereigncloudstack/csctl-builder:0.2.0

.github/workflows/pr-lint.yml

@@ -19,7 +19,7 @@ jobs:
     if: github.event_name != 'pull_request_target' || !github.event.pull_request.draft
     runs-on: ubuntu-latest
     container:
-      image: ghcr.io/sovereigncloudstack/csmctl-builder:0.2.0
+      image: ghcr.io/sovereigncloudstack/csctl-builder:0.2.0
       credentials:
         username: ${{ github.actor }}
         password: ${{ secrets.github_token }}

.github/workflows/schedule-link-checker.yml

@@ -8,7 +8,7 @@ jobs:
   link-checker:
     name: Link Checker
     runs-on: ubuntu-latest
-    if: github.repository == 'SovereignCloudStack/csmctl'
+    if: github.repository == 'SovereignCloudStack/csctl'
     steps:
       - name: Checkout
         uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1

.github/workflows/schedule-update-bot.yaml

@@ -25,7 +25,7 @@ env:
 # yamllint disable rule:line-length
 jobs:
   update-bot:
-    if: github.repository == 'SovereignCloudStack/csmctl'
+    if: github.repository == 'SovereignCloudStack/csctl'
     name: Renovate
     runs-on: ubuntu-latest
     steps:
@@ -49,7 +49,7 @@ jobs:
         env:
           RENOVATE_HOST_RULES: '[{"hostType": "docker", "matchHost": "ghcr.io", "username": "${{ github.actor }}", "password": "${{ secrets.GITHUB_TOKEN }}" }]'
           RENOVATE_ALLOWED_POST_UPGRADE_COMMANDS: '[".*"]'
-          BUILDER_IMAGE: 'ghcr.io/sovereigncloudstack/csmctl-builder'
+          BUILDER_IMAGE: 'ghcr.io/sovereigncloudstack/csctl-builder'
           RENOVATE_POST_UPGRADE_TASKS: '{ commands: ["BUILD_IMAGE_TOKEN=${{ secrets.GITHUB_TOKEN }} BUILD_IMAGE_USER=${{ github.actor }} CI=true ./hack/upgrade-builder-image.sh"], fileFilters: ["Makefile", ".github/**/*.yml", ".builder-image-version.txt", ".github/**/*.yaml"], executionMode: "branch"}'
         with:
           configurationFile: ${{ env.RENOVATE_CONFIG_FILE }}

.gitignore

@@ -16,6 +16,6 @@ temp
 .reports
 # build and release
 dist
-csmctl
+csctl
 tmp/
 releases/

.goreleaser.yaml

@@ -1,7 +1,7 @@
-project_name: csmctl
+project_name: csctl
 
 builds:
-  - binary: csmctl
+  - binary: csctl
     goos:
       - linux
     goarch:

Makefile

@@ -18,7 +18,7 @@
 TAG ?= dev
 ARCH ?= amd64
 IMAGE_PREFIX ?= ghcr.io/sovereigncloudstack
-BUILDER_IMAGE = $(IMAGE_PREFIX)/csmctl-builder
+BUILDER_IMAGE = $(IMAGE_PREFIX)/csctl-builder
 BUILDER_IMAGE_VERSION = $(shell cat .builder-image-version.txt)
 
 # Certain aspects of the build are done in containers for consistency (e.g. protobuf generation)
@@ -44,8 +44,8 @@ export GOBIN := $(abspath $(TOOLS_BIN_DIR))
 # Common #
 ##########
 .PHONY: build
-build: ## build the csmctl binary
-	go build -o csmctl main.go
+build: ## build the csctl binary
+	go build -o csctl main.go
 
 .PHONY: lint-golang
 lint-golang: ## Lint Golang codebase

README.md

@@ -1,11 +1,12 @@
-# CSMCTL
+# CSCTL
 
 ## Table of Contents
 
-- [CSMCTL](#csmctl)
+- [CSCTL](#csctl)
   - [Table of Contents](#table-of-contents)
   - [Introduction](#introduction)
-  - [Features of csmctl](#features-of-csmctl)
+  - [Features of csctl](#features-of-csctl)
+  - [Docs](#docs)
 
 ## Introduction
 
@@ -16,18 +17,18 @@ Users can take existing releases of Cluster Stacks and the operator and will be
 This project facilitates building node image artifacts and release assets that can be used with the Cluster Stack Operator.
 
 
-## Features of csmctl
+## Features of csctl
 1. Testing and quick iterations
-csmctl is created with a single focus of building Cluster Stacks and testing them with Cluster Stack Operator quickly. This tool helps in doing quick iterations and facilitates testing Cluster Stacks. 
+csctl is created with a single focus of building Cluster Stacks and testing them with Cluster Stack Operator quickly. This tool helps in doing quick iterations and facilitates testing Cluster Stacks. 
 
 2. Versioning
-When configuring Cluster Stacks, it is necessary to put versions in the configuration, e.g. to version a Helm chart or node images. This process is facilitated by the csmctl through its own templating and mechanism to generate the right version, based on the content hash (for testing) or on a previous version (stable or beta channel). Users only have to use the right templating and the csmctl will do all the versioning automatically.
+When configuring Cluster Stacks, it is necessary to put versions in the configuration, e.g. to version a Helm chart or node images. This process is facilitated by the csctl through its own templating and mechanism to generate the right version, based on the content hash (for testing) or on a previous version (stable or beta channel). Users only have to use the right templating and the csctl will do all the versioning automatically.
 
 3. Plugin mechanism for providers
-The plugin mechanism of csmctl allows providers to implement all provider-specific steps that are needed for this provider. This can contain a fully automated building and uploading process for node images, which can be referenced in the Cluster Stack (using the templating logic for versioning). 
+The plugin mechanism of csctl allows providers to implement all provider-specific steps that are needed for this provider. This can contain a fully automated building and uploading process for node images, which can be referenced in the Cluster Stack (using the templating logic for versioning). 
 
 4. Automated testing of Cluster Stacks
-The csmctl enables automated testing of Cluster Stacks if integrated in a CI process that first builds all necessary files as well as node images (if needed) and then uses them to create a workload cluster based on the Cluster Stack.
+The csctl enables automated testing of Cluster Stacks if integrated in a CI process that first builds all necessary files as well as node images (if needed) and then uses them to create a workload cluster based on the Cluster Stack.
 
 ## Docs
 

docs/README.md

@@ -1,19 +1,19 @@
-# csmctl documentation
+# csctl documentation
 
 ## Build your own Cluster Stack
 
-Using csmctl to build a Cluster Stack requires a certain directory structure. See [here](./preparing_your_clusterstack_directory.md) for more details. 
+Using csctl to build a Cluster Stack requires a certain directory structure. See [here](./preparing_your_clusterstack_directory.md) for more details. 
 
 ## Building your own plugin
 
 If you need a plugin for your provider and your Cluster Stack that automates building and uploading of node images.
 
-## Using csmctl
+## Using csctl
 
-Do you have your Cluster Stack configured already? Is your plugin ready if you need it? Then check out [how to use](how_to_use_csmctl.md) the CLI tool!
+Do you have your Cluster Stack configured already? Is your plugin ready if you need it? Then check out [how to use](how_to_use_csctl.md) the CLI tool!
 
-## Developing and testing csmctl
+## Developing and testing csctl
 
-You want to improve or test `csmctl`?
+You want to improve or test `csctl`?
 
-You can find the introduction in [developing and testing csmctl](./developing-and-testing-csmctl.md)
+You can find the introduction in [developing and testing csctl](./developing-and-testing-csctl.md)

docs/design.md

@@ -1,4 +1,4 @@
-# CSMCTL - Design document
+# CSCTL - Design document
 
 # Introduction
 
@@ -20,7 +20,7 @@ The current process of building cluster stacks is rather cumbersome and error-pr
 
 # Proposal
 
-We propose a CLI tool called “csmctl”, which stands for cluster-stack-manager-ctl. This CLI tool should take over all manual work from a developer implementing cluster stacks that can be taken over. The developer should concentrate only on implementing the cluster stacks themselves.
+We propose a CLI tool called “csctl”, which stands for cluster-stack-manager-ctl. This CLI tool should take over all manual work from a developer implementing cluster stacks that can be taken over. The developer should concentrate only on implementing the cluster stacks themselves.
 
 There will be still a certain way of dealing with “cluster stack-specific” jobs, e.g. following a certain templating pattern. This is necessary, as the configuration and Helm Charts that developers implement are very generic.
 
@@ -40,24 +40,24 @@ A developer who has to think about how to version a cluster stack that was imple
 
 If multiple developers work on one cluster stack, they might interfere with each other’s work. Assuming that node images have to be built, then one developer would upload the node images in version “v2”, as the previous version was “v1”. The second developer has the same thought and would either overwrite the already uploaded node images of the colleague or not be able to upload the images since they exist already. 
 
-The csmctl allows both developers to have independent versioning based on a git commit hash.
+The csctl allows both developers to have independent versioning based on a git commit hash.
 
 ### User story 4: Developer updating cluster stack that is used in production
 
-If a developer updates a cluster stack that is used in production, great care is needed. The csmctl allows the developer to safely test cluster stacks, e.g. with a beta channel, without touching cluster stacks that are used in production. 
-If everything works well, a production release can be generated with csmctl.
+If a developer updates a cluster stack that is used in production, great care is needed. The csctl allows the developer to safely test cluster stacks, e.g. with a beta channel, without touching cluster stacks that are used in production. 
+If everything works well, a production release can be generated with csctl.
 
 ### User story 5: Automated testing of cluster stacks
 
-Cluster stacks cannot be tested in the CI and with a normal Git PR flow. The csmctl allows this testing of individual PRs and therefore enables automated testing via CI.
+Cluster stacks cannot be tested in the CI and with a normal Git PR flow. The csctl allows this testing of individual PRs and therefore enables automated testing via CI.
 
 # Risks & Mitigations
 
 ### Two forms of templating
 
 Helm charts use Go templating with the notation `{{ .values.myvalue }}`. As a cluster stack consists usually of two Helm charts, this notation will be very common.
 
-However, the csmctl requires a different form of templating, additionally to the one of Helm. This comes from the versioning of the cluster stacks themselves. The Cluster addon version, for example, has to be the version of the respective Helm chart. The same goes for the `ClusterClass` object name.
+However, the csctl requires a different form of templating, additionally to the one of Helm. This comes from the versioning of the cluster stacks themselves. The Cluster addon version, for example, has to be the version of the respective Helm chart. The same goes for the `ClusterClass` object name.
 
  Users have to use the additional templating notation `<< .ClusterAddonVersion >>` while implementing cluster stacks.
 
@@ -67,42 +67,42 @@ The alternative to using a different notation for cluster stack templating would
 
 ## Generic vs provider-specific work
 
-Just like the Cluster Stack Operator, the csmctl also has a generic and a provider-specific part. The provider-specific part is optional.
+Just like the Cluster Stack Operator, the csctl also has a generic and a provider-specific part. The provider-specific part is optional.
 
-The generic work is done with a CLI tool that exists in the repository csmctl in SCS. The tool can be initialized with provider-specific binaries, similar to the way [packer](https://github.com/hashicorp/packer) does it.
+The generic work is done with a CLI tool that exists in the repository csctl in SCS. The tool can be initialized with provider-specific binaries, similar to the way [packer](https://github.com/hashicorp/packer) does it.
 
 ## Generic work
 
-The generic part of the csmctl is 
+The generic part of the csctl is 
 
 1. Calculate the right versions based on git commit hash or previous releases
-2. Template everything with csmctl templating (NOT Helm templating!!)
+2. Template everything with csctl templating (NOT Helm templating!!)
 3. Package the ClusterClass Helm Chart
 4. Package the ClusterAddon Helm Chart
 5. Generate metadata.yaml
 
 ## Provider-specific work
 
-The provider-specific part of csmctl would do anything necessary to provide node images to users. One common task could be to use packer to build images and to upload them somewhere they can be accessed by users.
+The provider-specific part of csctl would do anything necessary to provide node images to users. One common task could be to use packer to build images and to upload them somewhere they can be accessed by users.
 
 Of course, one task would also be to find the right version for the node images (e.g. v2 if something changed since v1, or simply the git commit hash)
 
 ## Configuration
 
-There are multiple ways of configuring the csmctl. They all have specific use cases and will be explained in the following
+There are multiple ways of configuring the csctl. They all have specific use cases and will be explained in the following
 
 ### Configuration file
 
-There is a configuration file called `csmctl.yaml` which contains all values that will never have to be changed for a specific cluster stack. It follows this pattern:
+There is a configuration file called `csctl.yaml` which contains all values that will never have to be changed for a specific cluster stack. It follows this pattern:
 
 ```yaml
-apiVersion: csmctl.clusterstack.x-k8s.io/v1alpha1
+apiVersion: csctl.clusterstack.x-k8s.io/v1alpha1
 config:
   kubernetesVersion: v1.27.7
   clusterStackName: ferrol
   provider:
     type: myprovider
-    apiVersion: myprovider.csmctl.clusterstack.x-k8s.io/v1alpha1
+    apiVersion: myprovider.csctl.clusterstack.x-k8s.io/v1alpha1
 		config: xyz
 ```
 
@@ -114,7 +114,7 @@ Via flags the user can specifiy everything that is important but which might cha
 
 ### Environment variables
 
-Environment variables can be used, for example, to specify tokens and passwords. csmctl has to validate that all required environment variables have been specified.
+Environment variables can be used, for example, to specify tokens and passwords. csctl has to validate that all required environment variables have been specified.
 
 ## Commands of CLI tool
 
@@ -143,7 +143,7 @@ There are multiple modes to create release assets following different versioning
 
 ### Stable
 
-The stable mode requires the developer to specify an existing GitHub repository (in the future other ways of storing release assets are possible) via environment variables. The csmctl will search for the latest release fitting to the configuration of provider, cluster stack name, and Kubernetes version (e.g. docker-ferrol-1-27-vXXX). Then it will download the required release assets and check whether anything has changed in the cluster addon and node image section. Depending on that information it will calculate the next version, e.g. v2 after v1, or will leave the version the same if nothing changed.
+The stable mode requires the developer to specify an existing GitHub repository (in the future other ways of storing release assets are possible) via environment variables. The csctl will search for the latest release fitting to the configuration of provider, cluster stack name, and Kubernetes version (e.g. docker-ferrol-1-27-vXXX). Then it will download the required release assets and check whether anything has changed in the cluster addon and node image section. Depending on that information it will calculate the next version, e.g. v2 after v1, or will leave the version the same if nothing changed.
 
 ### Hash
 
@@ -157,4 +157,4 @@ The beta mode is similar to the stable mode, except that it generates releases f
 
 ### Custom (e.g. for PRs)
 
-The custom mode is designed for PR purposes and supports automated testing. It accommodates versions formatted as v0.custom-pr123. Crucially, these versions must adhere to semantic versioning standards (semver) and are specifically intended as inputs for the csmctl tool.
+The custom mode is designed for PR purposes and supports automated testing. It accommodates versions formatted as v0.custom-pr123. Crucially, these versions must adhere to semantic versioning standards (semver) and are specifically intended as inputs for the csctl tool.