Contribute to Meshery Open Source

Set up a Meshery dev environment and make your first open source contribution.

Introduction

30 Second Summary

Contributing to a large cloud native project starts with one challenge that stops most people before they write a single line of code. Getting the development environment to actually work on your machine.

In this project, you will set up a complete Meshery contributor workstation from source, connect it to a local Kubernetes cluster, observe how Meshery's internal components interact in real-time, and prepare a code change following the exact workflow used by active contributors.

What You'll Build

You'll compile Meshery Server, watch its Operator deploy MeshSync and a NATS Broker into a live cluster, build the mesheryctl CLI from source, and push a properly signed commit ready for a Pull Request.

By the end of this project, you'll have:

  • A locally compiled Meshery Server and UI you can open in your browser at localhost:9081, serving from Go source code you control and can modify.
  • A live kind cluster where you can run kubectl and watch Meshery Operator, MeshSync, and Broker pods discover new workloads in real-time.
  • A mesheryctl CLI binary you built from source, reflecting a code improvement you made yourself and committed with proper DCO signoff.
  • Secret Mission: Audit one of Meshery's GitHub Actions workflows to understand how automated testing validates every contribution.

Are there any prerequisites?

This project assumes CKA-level Kubernetes knowledge, basic Go proficiency, and familiarity with Git and GitHub.

Your environment should already have Go, Node.js, make, gcc, Docker, kind, and kubectl installed.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters for your contributor journey.

Fork, Clone, and Create Your Kind Cluster

To contribute to Meshery, you need your own copy of the source code with Git remotes configured for both your fork and the upstream repository. This lets you pull the latest changes from the main project while pushing your own branches for pull requests.

You'll also spin up a local Kubernetes cluster using kind. Meshery connects to this cluster to deploy its Operator, MeshSync, and Broker components in later steps.

In this step, get ready to:
  • Fork and clone the Meshery repository with proper upstream remote configured.
  • Create a kind cluster for Meshery to connect to.
Fork and clone the Meshery repository

The open source contribution workflow starts with a fork. A fork creates your own copy of the repository on GitHub, where you can push changes without needing write access to the main project.

GitHub redirects you to your new fork at github.com/YOUR-USERNAME/meshery.

What is a fork?

A fork is a full copy of a repository under your own GitHub account. You push your changes to your fork, then open a Pull Request asking the maintainers to merge your changes into the original project.

  • Clone your fork to your local machine by running this command:
git clone https://github.com/[[GITHUB_USERNAME="YOUR-USERNAME"]]/meshery.git ~/meshery

You should see Git downloading the repository. This creates a meshery folder in your home directory.

Clone failing with permission errors?

Make sure you're cloning YOUR fork (your username in the URL), not the main meshery/meshery repository. If you see a 404, double-check that the fork completed on GitHub.

help me troubleshoot why git clone is failing for my Meshery fork

  • Move into the repository and configure the upstream remote by running these commands:
cd ~/meshery
git remote add upstream https://github.com/meshery/meshery
git fetch upstream

Why add an upstream remote?

Your origin remote points to your fork where you push branches. The upstream remote points to the main Meshery repository so you can pull the latest changes before starting new work.

Running git fetch upstream downloads all branches and tags from the main repo without modifying your local code.

You should see Git fetching branches and tags from the meshery/meshery repository.

Before you run the next command, what do you expect to see for each remote?

  • Verify your remotes are configured correctly by running:
git remote -v

You should see four lines: origin (fetch and push) pointing to your fork, and upstream (fetch and push) pointing to https://github.com/meshery/meshery.

Only see origin, no upstream?

Run git remote add upstream https://github.com/meshery/meshery again. If you get a "remote already exists" error, the remote is there but may have a typo. Run git remote remove upstream and add it again with the correct URL.

help me fix my Git remote configuration for Meshery

Create your kind cluster

Meshery needs a Kubernetes cluster to deploy its Operator, MeshSync, and Broker into. A kind cluster runs entirely inside Docker containers on your machine, so it's free and disposable.

  • Create a kind cluster named meshery-dev by running this command:
kind create cluster --name meshery-dev

What does this command do?

kind create cluster spins up a single-node Kubernetes cluster inside a Docker container. The --name meshery-dev flag gives it a specific name so you can reference it later with kubectl.

kind also automatically sets your kubectl context to the new cluster, so subsequent commands target it by default.

You should see output ending with a message confirming the cluster is ready.

What do you expect to see when you ask kubectl for information about this cluster?

  • Verify the cluster is running by checking its info:
kubectl cluster-info --context kind-meshery-dev

You should see the Kubernetes control plane running at https://127.0.0.1:<port> and CoreDNS running at a similar address. This confirms your cluster is healthy and ready for Meshery.

Seeing connection refused or cluster not found?

Make sure Docker is running. kind requires Docker to create cluster containers. Run docker ps to confirm Docker is responsive.

If you see a "no matching resources" error, the cluster may not have finished creating. Wait 30 seconds and try the kubectl cluster-info command again.

help me troubleshoot my kind cluster creation

Your local environment is locked and loaded. You have the Meshery source code, proper remotes for the contribution workflow, and a live Kubernetes cluster waiting. Next up, you'll compile Meshery from source and see it running in your browser.

Build and Run Meshery from Source

Your repository is cloned, remotes are configured, and your kind cluster is running. Now comes the moment that proves your development environment actually works: compiling Meshery from source and seeing its UI load in your browser.

Many newcomers to open source get stuck at this exact stage. Build systems have hidden assumptions about dependencies and ordering. This step walks you through the correct sequence so you get the first visible win: Meshery's UI loading from code you compiled yourself.

In this step, get ready to:
  • Install UI dependencies and compile the React/Next.js frontend.
  • Build and run Meshery Server from Go source.
  • Verify Meshery detects your kind cluster automatically.
Install UI dependencies and build the frontend

Meshery's UI is a Next.js application that must be compiled into static assets before the server can serve it. The build happens in two stages: installing Node packages, then compiling the UI.

  • Install the UI dependencies by running this command from the meshery directory:
make ui-setup

What does this command do?

This runs npm install under the hood, pulling all the JavaScript packages the UI needs. It takes a few minutes depending on your network speed.

You should see npm output scrolling in your terminal, finishing without errors.

  • Compile the UI into static assets by running:
make ui-build

What does this command do?

This compiles both the Meshery UI and Provider UI using Next.js with the SWC compiler. The output is a set of static assets that Meshery Server will serve at http://localhost:9081.

This step also takes several minutes. The UI must be built before the server can display anything in the browser.

Wait for the build to complete. You should see the compilation finish without error messages.

Seeing build errors?

  • Make sure you are running these commands from the root meshery directory, not a subdirectory.
  • Confirm Node is available by running node --version. You need Node 22 LTS.
  • If make ui-setup failed partway, delete the ui/node_modules folder and run it again.

help me troubleshoot my Meshery UI build errors

Build and run Meshery Server from source

With the UI compiled, you can now build and start the Go server that powers Meshery. This single command compiles the Go code and immediately starts the server process.

  • Build and start Meshery Server by running:
make server

What does this command do?

This compiles the Go source code into a binary and runs it in one step. The server starts listening on port 9081.

Watch the terminal output for startup messages. The server will keep running in this terminal, so you will need to leave it open. Any time you change Go code later, stop the server with Ctrl+C and re-run make server.

Before you open the browser, what do you think you will see at http://localhost:9081?

  • Open http://localhost:9081 in your browser.

You should see the Meshery Provider selection screen. This is your first visible proof that the code you compiled is actually running.

  • Select Meshery as your Provider from the selection screen.

What is a Provider?

Meshery uses Providers to handle authentication and session persistence. The Meshery provider is the development provider you will use for local contributor work. Selecting it lets you proceed into the Meshery dashboard.

Server not starting or page not loading?

  • If you see a GORM/sqlite error, delete the ~/.meshery/config directory and re-run make server.
  • If the page shows nothing, confirm you ran make ui-build successfully before starting the server.
  • Make sure port 9081 is not already in use by another process.

help me fix Meshery Server not starting or loading in my browser

Verify Meshery detects your kind cluster

Meshery Server automatically looks for clusters in your ~/.kube/config file. Since your kind cluster is running, Meshery should have already detected it and begun deploying its components into it.

  • In the Meshery UI, click Lifecycle in the left menu.
  • Click Connections.

Do you think your kind cluster will already appear as Connected, or will you need to add it manually?

Your kind-meshery-dev cluster should appear in the list, auto-detected from your kubeconfig. If its status shows Connected, Meshery has already started deploying the Operator, MeshSync, and Broker into your cluster.

Why does auto-detection work?

When Meshery Server runs outside a cluster (like on your local machine), it reads $HOME/.kube/config and automatically attempts to connect to every cluster it finds there. Your kind cluster created the kubeconfig entry, so Meshery finds and connects to it without any manual step.

Cluster not showing up?

  • Confirm your kind cluster is still running by opening a new terminal and running kubectl cluster-info --context kind-meshery-dev.
  • Give it a minute. It can take 30-60 seconds for auto-detection to complete after server startup.
  • Refresh the Connections page if the cluster does not appear immediately.

help me troubleshoot why Meshery is not detecting my kind cluster

You just compiled a production-grade cloud native management platform from source and ran it locally. Next, you will dive into the cluster to see exactly what Meshery deployed and how its architecture works from the inside.

Observe the Architecture in Action

You have Meshery compiled from source and running in your browser. That proves you can build the project. Now it is time to understand how Meshery actually works under the hood.

Understanding how Meshery's internal components interact is what separates a user from a contributor. In this step, you will watch the Meshery Operator deploy MeshSync and the NATS Broker into your cluster in real-time, then see MeshSync discover resources and stream them back to the Server.

In this step, get ready to:
  • Inspect the Meshery components deployed in your kind cluster.
  • Deploy a sample workload and watch MeshSync discover it automatically.
  • Examine the Broker (NATS) communication between MeshSync and Meshery Server.
Inspect the Meshery components in your kind cluster

When you connected your kind cluster in the previous step, Meshery Server instructed the Meshery Operator to deploy its companion components into the cluster. Let's confirm they are running.

  • List all resources in the meshery namespace by running this command:
kubectl get all -n meshery --context kind-meshery-dev

You should see a meshery-operator Deployment, a meshery-broker StatefulSet, and a meshery-meshsync Deployment listed in the output, along with their Pods and ReplicaSets.

What are these three components?

Meshery Operator is a Kubernetes controller built with Kubebuilder. It watches for MeshSync and Broker custom resources, then reconciles them into real workloads (Deployments, StatefulSets).

MeshSync registers Kubernetes informers for watched resource types, detecting ADDED, MODIFIED, and DELETED events. It publishes those events to the Broker.

The Broker is a NATS-based message bus deployed as a StatefulSet. Meshery Server subscribes to its subjects to receive cluster state without polling.

  • Check the Custom Resource Definitions that the Operator installed by running:
kubectl get crd | grep meshery

You should see brokers.meshery.io and meshsyncs.meshery.io listed. These CRDs tell the Operator what to deploy.

  • Inspect the MeshSync custom resource to see its configuration by running:
kubectl get meshsyncs -n meshery --context kind-meshery-dev -o yaml

In the YAML output, look for the watch-list (which resource types MeshSync monitors) and the broker configuration showing the NATS connection URL.

Not seeing pods in the meshery namespace?

It can take 30-60 seconds for the Operator to finish deploying MeshSync and the Broker after your cluster connects. Wait a moment and re-run the kubectl get all command.

If the pods still do not appear, switch back to the Meshery UI and check that your cluster shows as Connected under Lifecycle > Connections.

help me troubleshoot why Meshery Operator hasn't deployed pods into the meshery namespace

Deploy a sample workload and watch MeshSync discover it

MeshSync is already watching your cluster for changes. Let's deploy something new and see how quickly MeshSync picks it up and streams it to the Meshery UI.

  • Create an nginx deployment in the default namespace by running:
kubectl create deployment nginx --image=nginx --context kind-meshery-dev
  • Expose the nginx deployment as a Service on port 80 by running:
kubectl expose deployment nginx --port=80 --context kind-meshery-dev

Both commands should output confirmation messages showing the deployment and service were created.

  • Switch back to the Meshery UI in your browser.
  • Within seconds, MeshSync discovers the new nginx deployment and service. You can see them appear in the UI without any manual refresh.

How did MeshSync discover that so fast?

MeshSync uses Kubernetes informers to watch for resource events in real-time. When you created the nginx Deployment, the Kubernetes API server immediately fired an ADDED event.

MeshSync received that event, serialized the resource, and published it to the meshery.meshsync.core NATS subject on the Broker. Meshery Server subscribes to that subject and updates the UI instantly.

Examine the Broker communication

You have seen MeshSync discover a workload. Now let's look at the NATS Broker that carries these messages between MeshSync and Meshery Server.

  • View the Broker's recent NATS activity by running:
kubectl logs -n meshery -l app=meshery-broker --tail=20 --context kind-meshery-dev

You should see NATS connection and subscription log lines showing active messaging.

  • Confirm the Operator injected the Broker URL into MeshSync by running:
kubectl describe meshsync meshery-meshsync -n meshery --context kind-meshery-dev

In the output, look for the BROKER_URL field. This is how the Operator tells MeshSync where to publish events.

What does this confirm about the architecture?

The Operator manages the lifecycle of both the Broker and MeshSync. When it creates MeshSync, it injects the Broker's internal cluster address so MeshSync knows exactly where to publish. Meshery Server, running outside the cluster, establishes a self-healing port-forward to the Broker's NATS pod to subscribe.

The data flow is: MeshSync publishes to the meshery.meshsync.core NATS subject, and Meshery Server subscribes to receive resource events.

Before you run the final check, do you think all three Meshery components are still running healthy after the nginx deployment you added?

  • Verify all Meshery pods are running by executing:
kubectl get pods -n meshery --context kind-meshery-dev

You should see meshery-operator, meshery-broker, and meshery-meshsync pods all showing Running status. All three working together is what gives Meshery its real-time cluster awareness.

Seeing a pod in CrashLoopBackOff?

If the meshery-broker pod is restarting, it may be a resource constraint on your kind cluster. Check events with kubectl describe pod -n meshery -l app=meshery-broker --context kind-meshery-dev and look for OOMKilled or scheduling errors.

help me fix a Meshery pod stuck in CrashLoopBackOff on my kind cluster

You now have a firsthand view of Meshery's internal architecture. The Operator manages MeshSync and the Broker, MeshSync watches and publishes, and the Server subscribes and renders. Next up, you will build the mesheryctl CLI from source and explore the codebase for your first contribution.

Build mesheryctl from Source and Explore the Codebase

You've seen how Meshery's internal components talk to each other inside your kind cluster. Now it's time to build the tool you'll actually modify for your first contribution: mesheryctl.

mesheryctl is the most contributor-friendly component in the Meshery project. It's a standalone Go binary built with the Cobra CLI framework, and changes to it don't require restarting the entire Meshery Server.

In this step, get ready to:
  • Build the mesheryctl binary from source and confirm it runs.
  • Explore the Cobra-based command structure so you know where to make changes.
Build the mesheryctl binary

The mesheryctl source code lives in its own folder within the Meshery repository. You'll navigate there and use the project's Makefile to compile it into a binary.

  • In the terminal where you've been running kubectl commands, navigate to the mesheryctl directory by running:
cd ~/meshery/mesheryctl
  • Build the mesheryctl binary by running:
make

What does this command do?

The Makefile in the mesheryctl directory compiles the Go source into a standalone binary called mesheryctl in the current directory.

This is the same binary that Meshery users install globally. You're building it straight from source so you can modify and test it locally.

You should see Go compilation output in your terminal as the binary is built.

Before you run the next command, what do you think the output will show? The binary was just compiled from your local source code.

  • Confirm the binary works by running:
./mesheryctl version

You should see a table with version information showing the Client build version and Git SHA. The Server row may also populate since Meshery Server is running in your other terminal.

Seeing a build error?

Make sure you're in the ~/meshery/mesheryctl directory, not the repository root. The Makefile for mesheryctl lives specifically in this subdirectory.

If you see Go version errors, confirm your Go version with go version. The project requires Go 1.25+ for mesheryctl.

Help me debug a mesheryctl build failure

Explore the codebase structure

Now that you have a working binary, you need to understand how the code is organized before you can modify it. Every CLI command maps to a specific Go file in a predictable directory structure.

  • List the command groups by running:
ls internal/cli/root/

You should see folders like system, mesh, filter, and others. Each folder is a command group (like mesheryctl system, mesheryctl mesh).

How does Cobra organize commands?

Cobra is a Go library for building CLI applications. Each command is defined as a cobra.Command struct with fields that Cobra uses to generate help text, validate input, and run the command logic.

The CLI reference docs on the Meshery website are auto-generated from these structs via GitHub Actions. Improving a command description in code also improves the official docs.

  • Open internal/cli/root/system/status.go in your code editor.

Look for the cobra.Command struct definition in this file. You'll see fields like Use, Short, Long, Example, and RunE.

What do these Cobra fields mean?

  • Use defines the command name and usage pattern.
  • Short is the one-line description shown in help listings.
  • Long is the detailed description shown when the user runs --help on that specific command.
  • Example provides usage examples displayed in help output.
  • RunE contains the function that executes when the command is invoked.
  • Verify you can see the pattern in action by running:
./mesheryctl system status --help

Compare the help output you see in your terminal with the Short, Long, and Example fields in the source file you just opened. The text maps directly from code to CLI output.

  • Now open internal/cli/root/config/config.go in your code editor.

This file contains the central config struct that mesheryctl uses to read and write ~/.meshery/config.yaml. It uses Viper (a Go configuration library) to manage the config file.

Why does this matter for contributors?

When you modify a command in the next step, you'll be editing these exact Cobra struct fields. The pattern is always the same: find the command's Go file, update the struct fields, rebuild with make, and test with --help.

You now have a working mesheryctl binary and you understand the code structure behind it. Next up, you'll make an actual code change and prepare it as a contribution with proper DCO signoff.

Make a Code Change and Prepare a Contribution

You have a working mesheryctl binary and you understand the Cobra command structure inside it. Now it's time to do what you set up this entire environment for: contribute code.

Every Meshery contribution follows the same workflow: branch, change, build, test, sign off, push. In this step, you'll modify a mesheryctl command file and prepare it as a properly signed-off commit ready for a Pull Request.

In this step, get ready to:
  • Create a feature branch for your code change.
  • Modify a mesheryctl command file with a meaningful improvement.
  • Commit with DCO signoff and push to your fork.
Create a feature branch and make a change

Every code change starts on its own branch. This keeps your work isolated from the main codebase and makes Pull Requests clean.

  • Navigate back to the repository root by running this command:
cd ~/meshery
  • Create and switch to a new feature branch by running:
git checkout -b feat/improve-mesheryctl-output

You should see a message confirming you switched to the new branch.

Why a feature branch?

Feature branches let you work on changes without affecting the main branch. When you open a Pull Request, it compares your feature branch against the upstream master branch, showing only the changes you made.

Now you'll make a meaningful improvement to a mesheryctl command file. You already explored mesheryctl/internal/cli/root/system/status.go in the previous step, so you know its Cobra command structure.

  • Open mesheryctl/internal/cli/root/system/status.go in your code editor.

Look for the cobra.Command struct with its Use, Short, Long, Example, and RunE fields.

✔️ I'll give it a go!

Pick one of these improvements to make:

  • Enhance the Long description to be more helpful for new users.
  • Add a missing example to the Example field.
  • Improve an error message to be more descriptive.
  • Improve the Short help text to better describe what the command does.

Make your edit and save the file.

ⓧ Maybe a little help...

Here's a concrete example. Find the Example field in the cobra.Command struct. If it's empty or has only one example, add a new usage example that shows a flag or common use case.

Alternatively, find the Long field and expand the description to explain what the command checks, what output the user can expect, and when they'd want to use it.

Save the file after making your edit.

Why these changes count as real contributions

Meshery's CLI reference docs are auto-generated from these Cobra structs via GitHub Actions. When you improve a command's Long or Example fields, you improve both the CLI help output and the published documentation.

Rebuild and verify your change

You need to recompile mesheryctl to see your change reflected in the help output.

  • Rebuild the mesheryctl binary by running:
cd mesheryctl && make

You should see the build complete without errors.

Seeing a build error?

If you see a syntax error, go back to status.go and check for missing quotes, unclosed backticks in the Example field, or mismatched parentheses. Go string literals must be properly terminated.

help me debug a Go build error in mesheryctl

Before you run the next command, what do you expect to see in the help output? Think about where your change should appear.

  • Verify your change appears in the help output by running:
./mesheryctl system status --help

You should see your improved text in the help output. If you enhanced the Long field, it appears in the description section. If you added an Example, it appears under the examples heading.

  • Return to the repository root by running:
cd ..
Commit with DCO signoff and push

Meshery requires all contributions to include a DCO (Developer Certificate of Origin) signoff. This certifies that you have the right to submit the code you're contributing.

  • Stage your changes by running:
git add .
  • Commit your change with DCO signoff by running:
git commit -s -m "Improve mesheryctl system status command description"

What does the -s flag do?

The -s flag automatically adds a Signed-off-by: Your Name <your@email.com> line to the end of your commit message. It uses the name and email from your Git configuration.

Without this trailer, Meshery's CI will reject your Pull Request. Every commit to the Meshery repository must be signed off.

Before you check the log, what do you expect the commit to look like? Think about what the -s flag added.

  • Confirm your commit has the signoff trailer by running:
git log --oneline -1

You should see your commit message with the DCO signoff. To see the full commit including the Signed-off-by trailer, run:

git log -1

The output should include a line like Signed-off-by: Your Name <your@email.com> at the bottom of the commit message.

Don't see the Signed-off-by line?

Make sure your Git config has your name and email set. Run git config user.name and git config user.email to check. If either is empty, set them and amend the commit with git commit --amend -s.

help me fix my DCO signoff on a Git commit

  • Push your branch to your fork by running:
git push origin feat/improve-mesheryctl-output

You should see Git push output confirming the branch was created on your remote.

What happens next in a real contribution?

You would now open a Pull Request on GitHub targeting the upstream meshery/meshery repository. All Meshery PRs must reference an open issue. Browse the issues labeled help wanted or good first issue to find one that matches your change.

Secret mission

Explore Meshery's CI/CD Pipeline

You've built, run, and contributed to Meshery. Now go deeper. Audit the GitHub Actions workflows that validate every contribution to the repository. This is the exact skill the "Agentic CI Pipelines" LFX project requires: understanding how automated testing guards the codebase, identifying security patterns, and spotting opportunities for improvement.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally, so there are no ongoing costs.

Resources you used:

  • A kind cluster named meshery-dev (runs locally, no cost).
  • Meshery components inside the kind cluster (Operator, MeshSync, Broker pods in the meshery namespace).
  • A sample nginx deployment and service in the default namespace.
  • Meshery source code cloned to ~/meshery.
  • Your fork of the Meshery repository on GitHub.

Keep everything running

No action needed. Choose this if you plan to continue contributing to Meshery or want to pick up a help-wanted issue next.

  • Stop Meshery Server with Ctrl+C in the terminal and restart anytime with make server.
  • The kind cluster stays up and uses minimal resources when idle.
  • Your fork on GitHub persists separately. You can open a Pull Request whenever you're ready.

Pause - I'll come back to this later

Shut down running processes to free up memory. Your files and cluster stay intact for when you return.

  • Stop Meshery Server by pressing Ctrl+C in the terminal where it is running.
  • The kind cluster remains up but uses minimal resources when idle. Meshery components inside it will stay running but won't do much without the Server.
  • When you're ready to resume, navigate back to ~/meshery and run make server to start again.

Delete - I don't want to use this again

Remove all project resources and start fresh. This is irreversible for local state.

  • Stop Meshery Server by pressing Ctrl+C in the terminal where it is running.
  • Delete the kind cluster (this removes all Meshery components, the nginx deployment, and everything in the cluster) by running:
kind delete cluster --name meshery-dev
  • Remove the Meshery source code from your machine by running:
rm -rf ~/meshery
  • Your fork on GitHub persists separately. If you want to delete it, go to your fork's Settings page on GitHub, scroll to the bottom, and click Delete this repository.

Nice Work!

Nice Work!

You've just built a complete Meshery contributor workstation from source. You compiled the server, watched the architecture come alive inside a Kubernetes cluster, and prepared a real code change ready for a Pull Request.

You've learned how to:

  • Built Meshery Server and the React/Next.js UI from source using Makefile-driven workflows, serving a fully functional dashboard at localhost:9081.
  • Observed the full Meshery architecture in action: Meshery Operator deploying MeshSync and the Broker into a kind cluster, with MeshSync discovering workloads via Kubernetes informers and streaming events through NATS to Meshery Server.
  • Built the mesheryctl CLI from source, explored its Cobra-based command structure, made a code change, and committed it with proper DCO signoff ready to submit as a Pull Request.
  • Explored Meshery's CI/CD pipeline by auditing a GitHub Actions workflow and understanding how automated testing validates contributions (Secret Mission).

Ready to quiz yourself?