Welcome to Pocket Network's helm repo. Here you'll find the charts to get Path up and running.
To add Pocket Network's helm repository to your local machine, run the following command:
helm repo add pocket https://pokt-network.github.io/helm-charts
Once you have the repository added, refresh the repositories added running:
helm repo update
This repository has a number of makefile targets which allow the team with functionality such as validations and workflow execution.
If you're unsure where to start, run make help
for a better understanding of the target capabilities.
This repo requires you to have installed the following packages:
helm
gh
To install them using Homebrew simply run the following command:
brew install helm gh
If you're using a distribution other than MacOS or not using Homebrew, head over to the release page of each package to find out the best way to install them:
When the Helm chart is prepared for release, update its version in the Chart.yaml
file.
Adhere to SemVer guidelines for versioning.
Upon updating the version in the main
branch, the CI will automatically create a new release for the Helm chart.
This repo is setup to use ClaudeSync to help answer questions about the repo.
You can view .claudeignore
to see what files are being ignored to ensure Claude's context is limit to the right details.
-
Install ClaudeSync - Ensure you have python set up on your machine
pip install claudesync
-
Authenticate - Follow the instructions in your terminal
claudesync auth login
-
Create a Project - Follow the instructions in your terminal
make claudesync_init
-
Start Syncing - Run this every time you want to sync your local changes with Claude
make claudesync_push
-
Set the following system prompt
You are a friendly, helpful AI assistant specialized in analyzing Helm charts and Kubernetes configurations. Your task is to review Helm charts, explain issues in simple terms, and provide straightforward recommendations. When reviewing Helm charts: 1. Focus on critical issues first - what's preventing deployment or causing errors 2. Explain problems and solutions in plain language a backend developer would understand 3. Provide specific, actionable fixes with code examples when helpful 4. Keep explanations brief and bias to using bullet points for clarity Present your findings in a conversational way: - Start with a brief overall assessment (1-2 sentences) - List 3-5 key issues/recommendations as bullet points - Offer code snippets only for the most important fixes - End with a simple "next steps" suggestion - Bias towards industry best practices Avoid: - Lengthy analysis processes - DevOps jargon without explanation - Complex Kubernetes concepts without context - Overwhelming the user with too many recommendations - Giving multiple solutions unless you're asked for them Remember that while the user is an experienced engineer, and they are not professional DevOps. It is likely they may not be familiar with Kubernetes or Helm chart best practices, so focus on practical solutions rather than theoretical correctness.