Resolve Apple M1 Arch Support Issues

.gitlab-ci.yml

@@ -68,5 +68,6 @@ generate-release:
       --assets-link "{\"name\":\"zarf\",\"url\":\"https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$CI_COMMIT_TAG/zarf\"}"
       --assets-link "{\"name\":\"zarf-mac-apple\",\"url\":\"https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$CI_COMMIT_TAG/zarf-mac-apple\"}"
       --assets-link "{\"name\":\"zarf-mac-intel\",\"url\":\"https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$CI_COMMIT_TAG/zarf-mac-intel\"}"
-      --assets-link "{\"name\":\"zarf-init.tar.zst\",\"url\":\"https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$CI_COMMIT_TAG/zarf-init.tar.zst\"}"
+      --assets-link "{\"name\":\"zarf-init-amd64.tar.zst\",\"url\":\"https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$CI_COMMIT_TAG/zarf-init-amd64.tar.zst\"}"
+      --assets-link "{\"name\":\"zarf-init-arm64.tar.zst\",\"url\":\"https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$CI_COMMIT_TAG/zarf-init-arm64.tar.zst\"}"
       --assets-link "{\"name\":\"zarf.sha256\",\"url\":\"https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$CI_COMMIT_TAG/zarf.sha256\"}"

Makefile

@@ -2,6 +2,8 @@
 ZARF_BIN := ./build/zarf
 UNAME_S := $(shell uname -s)
 UNAME_P := $(shell uname -p)
+# Need a clean way to map this, arch and uname -a return x86_64 for amd64
+ARCH := amd64
 ifneq ($(UNAME_S),Linux)
 	ifeq ($(UNAME_S),Darwin)
 		ZARF_BIN := $(addsuffix -mac,$(ZARF_BIN))
@@ -49,8 +51,9 @@ build-cli-mac: ## Build the Mac CLI
 build-cli: build-cli-linux build-cli-mac ## Build the CLI
 
 init-package: ## Create the zarf init package, macos "brew install coreutils" first
-	$(ZARF_BIN) package create --confirm
-	mv zarf-init.tar.zst build
+	$(ZARF_BIN) package create --confirm --architecture amd64
+	$(ZARF_BIN) package create --confirm --architecture arm64
+	mv zarf-init-*.tar.zst build
 	cd build && sha256sum -b zarf* > zarf.sha256
 	ls -lh build
 
@@ -82,26 +85,26 @@ package-example-tiny-kafka:
 package-example-compose:
 	cd examples/composable-packages && ../../$(ZARF_BIN) package create --confirm && mv zarf-package-* ../../build/
 
-# TODO: This can be cleaned up a little more when `zarf init` is able to provide the path to the `zarf-init.tar.zst`
+# TODO: This can be cleaned up a little more when `zarf init` is able to provide the path to the `zarf-init-<arch>.tar.zst`
 .PHONY: test-new-e2e
 test-e2e: ## Run e2e tests on a KiND cluster. All dependencies are assumed to be built and in the ./build directory
 	@ #Check to make sure all the packages we need exist
 	@if [ ! -f $(ZARF_BIN) ]; then\
 		$(MAKE) build-cli;\
 	fi
-	@if [ ! -f ./build/zarf-init.tar.zst ]; then\
+	@if [ ! -f ./build/zarf-init-$(ARCH).tar.zst ]; then\
 		$(MAKE) init-package;\
 	fi
-	@if [ ! -f ./build/zarf-package-appliance-demo-multi-games.tar.zst ]; then\
+	@if [ ! -f ./build/zarf-package-appliance-demo-multi-games-$(ARCH).tar.zst ]; then\
 		$(MAKE) package-example-game;\
 	fi
-	@if [ ! -f ./build/zarf-package-data-injection-demo.tar ]; then\
+	@if [ ! -f ./build/zarf-package-data-injection-demo-$(ARCH).tar ]; then\
 		$(MAKE) package-example-data-injection;\
 	fi
-	@if [ ! -f ./build/zarf-package-gitops-service-data.tar.zst ]; then\
+	@if [ ! -f ./build/zarf-package-gitops-service-data-$(ARCH).tar.zst ]; then\
 		$(MAKE) package-example-gitops-data;\
 	fi
-	@if [ ! -f ./build/zarf-package-compose-example.tar.zst ]; then\
+	@if [ ! -f ./build/zarf-package-compose-example-$(ARCH).tar.zst ]; then\
 		$(MAKE) package-example-compose;\
 	fi
-	cd test/e2e && cp ../../build/zarf-init.tar.zst . && go test ./... -v -timeout 2400s && rm zarf-init.tar.zst
+	cd test/e2e && cp ../../build/zarf-init-$(ARCH).tar.zst . && go test ./... -v -timeout 2400s && rm zarf-init-$(ARCH).tar.zst

cli/cmd/initialize.go

@@ -22,7 +22,7 @@ var initCmd = &cobra.Command{
 		_, _ = fmt.Fprintln(os.Stderr, zarfLogo)
 
 		// Continue running package deploy for all components like any other package
-		config.DeployOptions.PackagePath = config.PackageInitName
+		config.DeployOptions.PackagePath = fmt.Sprintf("zarf-init-%s.tar.zst", config.GetArch())
 
 		// Run everything
 		packager.Deploy()

cli/cmd/root.go

@@ -21,12 +21,11 @@ var rootCmd = &cobra.Command{
 		if zarfLogLevel != "" {
 			setLogLevel(zarfLogLevel)
 		}
+		config.CliArch = arch
 	},
 	Short: "Small tool to bundle dependencies with K3s for air-gapped deployments",
 	Args:  cobra.MaximumNArgs(1),
 	Run: func(cmd *cobra.Command, args []string) {
-		config.CliArch = arch
-
 		if len(args) > 0 {
 			if strings.Contains(args[0], "zarf-package-") || strings.Contains(args[0], "zarf-init") {
 				config.DeployOptions.PackagePath = args[0]

cli/config/config.go

@@ -19,8 +19,7 @@ import (
 const (
 	IPV4Localhost = "127.0.0.1"
 
-	PackageInitName = "zarf-init.tar.zst"
-	PackagePrefix   = "zarf-package-"
+	PackagePrefix = "zarf-package"
 
 	// ZarfMaxChartNameLength limits helm chart name size to account for K8s/helm limits and zarf prefix
 	ZarfMaxChartNameLength = 40
@@ -102,11 +101,17 @@ func GetSeedImage() string {
 
 func GetPackageName() string {
 	metadata := GetMetaData()
+	prefix := PackagePrefix
+	suffix := "tar.zst"
+
+	if IsZarfInitConfig() {
+		return fmt.Sprintf("zarf-init-%s.tar.zst", GetArch())
+	}
+
 	if metadata.Uncompressed {
-		return PackagePrefix + metadata.Name + ".tar"
-	} else {
-		return PackagePrefix + metadata.Name + ".tar.zst"
+		suffix = "tar"
 	}
+	return fmt.Sprintf("%s-%s-%s.%s", prefix, metadata.Name, GetArch(), suffix)
 }
 
 func GetDataInjections() []types.ZarfData {

cli/internal/packager/create.go

@@ -68,9 +68,6 @@ func Create() {
 	}
 
 	if config.IsZarfInitConfig() {
-		// Override the package name for init packages
-		packageName = config.PackageInitName
-
 		// Include the injection things we need, note that zarf-registry must be created by `make build-injector` first
 		utils.CreatePathAndCopy("injector/zarf-registry", tempPath.injectZarfBinary)
 		utils.CreatePathAndCopy("injector/zarf-injector", tempPath.injectBinary)

cli/internal/packager/validate/validate.go

@@ -2,6 +2,7 @@ package validate
 
 import (
 	"fmt"
+	"regexp"
 	"strings"
 
 	"github.com/defenseunicorns/zarf/cli/config"
@@ -14,6 +15,10 @@ import (
 func Run() {
 	components := config.GetComponents()
 
+	if err := validatePackageName(config.GetMetaData().Name); err != nil {
+		message.Fatalf(err, "Invalid package name")
+	}
+
 	for _, component := range components {
 		for _, chart := range component.Charts {
 			if err := validateChart(chart); err != nil {
@@ -29,6 +34,15 @@ func Run() {
 
 }
 
+func validatePackageName(subject string) error {
+	// https://regex101.com/r/vpi8a8/1
+	isValid := regexp.MustCompile(`^[a-z\-]+$`).MatchString
+	if isValid(subject) {
+		return nil
+	}
+	return fmt.Errorf("package name '%s' must be all lowercase and contain no special characters except -", subject)
+}
+
 func validateChart(chart types.ZarfChart) error {
 	intro := fmt.Sprintf("chart %s", chart.Name)
 

docs/adr/0002-moving-e2e-tests-away-from-terratest.md

@@ -10,7 +10,7 @@ Accepted
 
 In previous releases of Zarf, the creation of the initialization package at the core of many of our E2E tests required repository secrets to login to registry1. Since this is an open-source project, anyone could submit a change to one of our GitHub workflows that could steal our secrets. In order to protect our secrets from any bad-actors we used [peter-evans/slash-command-dispatch@v2](https://github.com/peter-evans/slash-command-dispatch) so that only a maintainer would have the ability to run the E2E tests when a PR is submitted for review.
 
-In the current version of Zarf (v0.15) images from registry1 are no longer needed to create the zarf-init.tar.zst. This means, given our current span of E2E tests, we no longer need to use repository secrets when running tests. This gives us the ability to reassess the way we do our E2E testing.
+In the current version of Zarf (v0.15) images from registry1 are no longer needed to create the zarf-init-<arch>.tar.zst. This means, given our current span of E2E tests, we no longer need to use repository secrets when running tests. This gives us the ability to reassess the way we do our E2E testing.
 
 When considering how to handle the tests, some of the important additions we were considering were:
   1. Ability to test against different kubernetes distributions

docs/first-time-build.md

@@ -68,7 +68,7 @@ make init-package
 > ```
 > It is likely that you've forgotten to setup access to Iron Bank _or_ that your credentials have changed. In either case, you should go back through the steps to [Log into Iron Bank](#2-log-into-iron-bank) & try to build again!
 
-Assuming everything works out, you should see a shiny new `zarf-init.tar.zst` in your `./build` directory.
+Assuming everything works out, you should see a shiny new `zarf-init-<arch>.tar.zst` in your `./build` directory.
 
 Congratulations!  You've just built yourself a Zarf!
 

docs/workstation.md

@@ -16,7 +16,7 @@ The simplest path to Zarf is to download a pre-built release and execute it on y
 
 1. Download:
 
-    - The zarf cluster initialization package: `zarf-init.tar.zst`.
+    - The zarf cluster initialization package: `zarf-init-<arch>.tar.zst`.
 
     - The appropriate zarf binary for your system (choose _one_):
 
@@ -34,7 +34,8 @@ The simplest path to Zarf is to download a pre-built release and execute it on y
     shasum -c ./zarf.sha256
 
     > zarf: OK                  # <-- you should see "OK"s, like this
-    > zarf-init.tar.zst: OK
+    > zarf-init-amd64.tar.zst: OK
+    > zarf-init-arm64.tar.zst: OK
     > zarf-mac-apple: OK
     > zarf-mac-intel: OK
     ```

examples/Makefile

@@ -37,7 +37,7 @@ clean: ## Clean the sync dir
 fetch-release: ## Grab the latest release as an alternative to needing to build the binaries
 	@mkdir -p sync
 	@# This probably isn't the cleanest way to get a release, but since we're moving to github, not worth adding the code until post-migration
-	@curl -fL "https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$$(git describe --tags --abbrev=0)/{zarf,zarf-mac-intel,zarf-mac-apple,zarf-init.tar.zst}" -o "sync/#1"
+	@curl -fL "https://zarf-public.s3-us-gov-west-1.amazonaws.com/release/$$(git describe --tags --abbrev=0)/{zarf,zarf-mac-intel,zarf-mac-apple,zarf-init-amd64.tar.zst,zarf-init-arm64.tar.zst}" -o "sync/#1"
 	@chmod +x sync/*
 
 .PHONY: build-release

examples/big-bang/README.md

@@ -69,7 +69,7 @@ make vm-init
 
 ```shell
 # Deploy Big Bang
-./zarf package deploy --confirm zarf-package-big-bang-core-demo.tar.zst
+./zarf package deploy --confirm zarf-package-big-bang-core-demo-amd64.tar.zst
 
 # (Optional) Inspect the results
 ./zarf tools k9s

examples/composable-packages/README.md

@@ -64,7 +64,7 @@ kind create cluster
 This will result in a single-node Kubernetes cluster called `kind-kind` on your local machine running in Docker. Your KUBECONFIG should be automatically configured to talk to the new cluster.
 
 ```sh
-cd <same dir as zarf-init.tar.zst>
+cd <same dir as zarf-init-<arch>.tar.zst>
 zarf init
 ```
 
@@ -78,13 +78,13 @@ Congratulations!  Your machine is now running a single-node Kubernetes cluster p
 
 **Troubleshooting:**
 
-> _**ERROR:  Unable to find the package on the local system, expected package at zarf-init.tar.zst**_
+> _**ERROR:  Unable to find the package on the local system, expected package at zarf-init-<arch>.tar.zst**_
 >
 > The zarf binary needs an init package to know how to setup your cluster! So, if `zarf init` returns an error like this:
 > ```sh
-> ERROR:  Unable to find the package on the local system, expected package at zarf-init.tar.zst
+> ERROR:  Unable to find the package on the local system, expected package at zarf-init-<arch>.tar.zst
 > ```
-> It's likely you've either forgotten to download `zarf-init.tar.zst` (as part of [getting ready](#get-ready)) _**OR**_ you are _not_ running `zarf init` from the directory the init package is sitting in.
+> It's likely you've either forgotten to download `zarf-init-<arch>.tar.zst` (as part of [getting ready](#get-ready)) _**OR**_ you are _not_ running `zarf init` from the directory the init package is sitting in.
 
 > _**ERROR: failed to create cluster: node(s) already exist for a cluster with the name "kind"**_
 >
@@ -122,7 +122,7 @@ Watch the terminal scroll for a while. Once things are downloaded & zipped up an
 It's time to feed the package you built into your cluster.
 
 ```sh
-zarf package deploy ./zarf-package-compose-example.tar.zst --confirm
+zarf package deploy ./zarf-package-compose-example-<arch>.tar.zst --confirm
 ```
 
 In a couple seconds the cluster will have loaded your package.

examples/data-injection/README.md

@@ -50,7 +50,7 @@ kind create cluster
 This will result in a single-node Kubernetes cluster called `kind-kind` on your local machine running in Docker. Your KUBECONFIG should be automatically configured to talk to the new cluster.
 
 ```sh
-cd <same dir as zarf-init.tar.zst>
+cd <same dir as zarf-init-<arch>.tar.zst>
 zarf init
 ```
 
@@ -64,15 +64,15 @@ Congratulations! Your machine is now running a single-node Kubernetes cluster po
 
 **Troubleshooting:**
 
-> _**ERROR: Unable to find the package on the local system, expected package at zarf-init.tar.zst**_
+> _**ERROR: Unable to find the package on the local system, expected package at zarf-init-<arch>.tar.zst**_
 >
 > The zarf binary needs an init package to know how to setup your cluster! So, if `zarf init` returns an error like this:
 >
 > ```sh
-> ERROR:  Unable to find the package on the local system, expected package at zarf-init.tar.zst
+> ERROR:  Unable to find the package on the local system, expected package at zarf-init-<arch>.tar.zst
 > ```
 >
-> It's likely you've either forgotten to download `zarf-init.tar.zst` (as part of [getting ready](#get-ready)) _**OR**_ you are _not_ running `zarf init` from the directory the init package is sitting in.
+> It's likely you've either forgotten to download `zarf-init-<arch>.tar.zst` (as part of [getting ready](#get-ready)) _**OR**_ you are _not_ running `zarf init` from the directory the init package is sitting in.
 
 > _**ERROR: failed to create cluster: node(s) already exist for a cluster with the name "kind"**_
 >
@@ -110,7 +110,7 @@ It's time to feed the package you built into your cluster.
 Since you're running a Zarf cluster directly on your local machine&mdash;where this package & `zarf` binary _already are_&mdash;deploying the package is very simple:
 
 ```sh
-zarf package deploy zarf-package-data-injection-demo.tar --confirm
+zarf package deploy zarf-package-data-injection-demo-<arch>.tar --confirm
 ```
 
 In a couple seconds the cluster will have loaded your package.

examples/game/README.md

@@ -64,7 +64,7 @@ kind create cluster
 This will result in a single-node Kubernetes cluster called `kind-kind` on your local machine running in Docker. Your KUBECONFIG should be automatically configured to talk to the new cluster.
 
 ```sh
-cd <same dir as zarf-init.tar.zst>
+cd <same dir as zarf-init-<arch>.tar.zst>
 zarf init
 ```
 
@@ -78,13 +78,13 @@ Congratulations!  Your machine is now running a single-node Kubernetes cluster p
 
 **Troubleshooting:**
 
-> _**ERROR:  Unable to find the package on the local system, expected package at zarf-init.tar.zst**_
+> _**ERROR:  Unable to find the package on the local system, expected package at zarf-init-<arch>.tar.zst**_
 >
 > The zarf binary needs an init package to know how to setup your cluster! So, if `zarf init` returns an error like this:
 > ```sh
-> ERROR:  Unable to find the package on the local system, expected package at zarf-init.tar.zst
+> ERROR:  Unable to find the package on the local system, expected package at zarf-init-<arch>.tar.zst
 > ```
-> It's likely you've either forgotten to download `zarf-init.tar.zst` (as part of [getting ready](#get-ready)) _**OR**_ you are _not_ running `zarf init` from the directory the init package is sitting in.
+> It's likely you've either forgotten to download `zarf-init-<arch>.tar.zst` (as part of [getting ready](#get-ready)) _**OR**_ you are _not_ running `zarf init` from the directory the init package is sitting in.
 
 > _**ERROR: failed to create cluster: node(s) already exist for a cluster with the name "kind"**_
 >
@@ -128,7 +128,7 @@ It's time to feed the package you built into your cluster.
 Since you're running a Zarf cluster directly on your local machine&mdash;where the game package & `zarf` binary _already are_&mdash;deploying the game is very simple:
 
 ```sh
-zarf package deploy ./zarf-package-appliance-demo-multi-games.tar.zst --confirm
+zarf package deploy ./zarf-package-appliance-demo-multi-games-<arch>.tar.zst --confirm
 ```
 
 In a couple seconds the cluster will have loaded your package.

examples/game/add-logging.md

@@ -44,7 +44,7 @@ Installing a Zarf component is _really_ easy—you just have to let `zarf in
 Exactly like when you first created the game example cluster, you _move into the directory holding your init package_ and run:
 
 ```sh
-cd <same dir as zarf-init.tar.zst>
+cd <same dir as zarf-init-<arch>.tar.zst>
 zarf init
 ```
 

examples/gitops-data/README.md

@@ -51,7 +51,7 @@ zarf package create                # make the package
 ```
 
 Successful execution will create a package named
-`zarf-package-gitops-service-data.tar.zst`, the Zarf example package.
+`zarf-package-gitops-service-data-<arch>.tar.zst`, the Zarf example package.
 
 ## Deploying the Zarf Package
 
@@ -64,7 +64,7 @@ command to deploy the package, uploading the Git repositories to Gitea and the
 container images to the Docker registry.
 
 ```sh
-zarf package deploy zarf-package-gitops-service-data.tar.zst
+zarf package deploy zarf-package-gitops-service-data-<arch>.tar.zst
 ```
 
 ## Applying the Kustomization

examples/istio-with-separate-cert/README.md

@@ -64,7 +64,7 @@ make vm-init
 
 ```shell
 # Deploy Big Bang
-./zarf package deploy --confirm zarf-package-example-istio-with-separate-cert.tar.zst
+./zarf package deploy --confirm zarf-package-example-istio-with-separate-cert-amd64.tar.zst
 
 # (Optional) Inspect the results
 ./zarf tools k9s

examples/single-big-bang-package/README.md

@@ -47,7 +47,7 @@ kind create cluster
 This will result in a single-node Kubernetes cluster called `kind-kind` on your local machine running in Docker. Your KUBECONFIG should be automatically configured to talk to the new cluster.
 
 ```sh
-cd <same dir as zarf-init.tar.zst>
+cd <same dir as zarf-init-<arch>.tar.zst>
 zarf init
 ```
 
@@ -61,15 +61,15 @@ Congratulations! Your machine is now running a single-node Kubernetes cluster po
 
 **Troubleshooting:**
 
-> _**ERROR: Unable to find the package on the local system, expected package at zarf-init.tar.zst**_
+> _**ERROR: Unable to find the package on the local system, expected package at zarf-init-<arch>.tar.zst**_
 >
 > The zarf binary needs an init package to know how to setup your cluster! So, if `zarf init` returns an error like this:
 >
 > ```sh
-> ERROR:  Unable to find the package on the local system, expected package at zarf-init.tar.zst
+> ERROR:  Unable to find the package on the local system, expected package at zarf-init-<arch>.tar.zst
 > ```
 >
-> It's likely you've either forgotten to download `zarf-init.tar.zst` (as part of [getting ready](#get-ready)) _**OR**_ you are _not_ running `zarf init` from the directory the init package is sitting in.
+> It's likely you've either forgotten to download `zarf-init-<arch>.tar.zst` (as part of [getting ready](#get-ready)) _**OR**_ you are _not_ running `zarf init` from the directory the init package is sitting in.
 
 > _**ERROR: failed to create cluster: node(s) already exist for a cluster with the name "kind"**_
 >
@@ -105,7 +105,7 @@ It's time to feed the package you built into your cluster.
 Since you're running a Zarf cluster directly on your local machine&mdash;where this package & `zarf` binary _already are_&mdash;deploying the package is very simple:
 
 ```sh
-zarf package deploy zarf-package-big-bang-single-package-demo.tar.zst --confirm
+zarf package deploy zarf-package-big-bang-single-package-demo-amd64.tar.zst --confirm
 ```
 
 In a couple seconds the cluster will have loaded your package.