# make-argocd-fly
[](https://img.shields.io/endpoint?url=https://gist.githubusercontent.com/Karandash8/26eb92c97bbfac22b938afebac85e7cd/raw/covbadge.json)
## Description
`make-argocd-fly` simplifies generation of Kubernetes manifests in multi-cluster and multi-application environments. It leverages YAML, Jinja2 templates, Kustomize files, and Helm charts through Kustomize, streamlining the process of creating and maintaining Kubernetes resources. Although the generated manifests can be deployed using any external tool, such as kubectl, `make-argocd-fly` provides native integration with ArgoCD, enhancing the overall deployment experience.
With `make-argocd-fly`, you can develop resources in various formats, specify deployment details in a configuration file, generate the final manifests effortlessly, and push them to a repository for ArgoCD to deploy to a Kubernetes cluster. This approach promotes transparency in what is being deployed and where, simplifies both maintenance and development, and assists in debugging issues.
## Features
- **ArgoCD App-of-Apps Pattern Support:** Native support for the app-of-apps pattern to organize complex applications, with automatic generation of ArgoCD `Application` resources for streamlined deployment.
- **Jinja2 and Kustomize Rendering:** Effortlessly render Kubernetes manifests using Jinja2 templates and Kustomize, including support for Helm charts.
- **Extended Jinja2 Functionality:** Includes additional Jinja2 extensions and filters, such as `include_raw`, to render content from external files.
- **Flexible Variable Management:** Manage global, per-environment, and per-application Jinja2 variables, with support for referencing other variables.
- **Subdirectory Resource Management:** Organize resources within subdirectories for improved structure and management.
## How to start
### Prerequisites
- `libyaml` is expected to be installed locally for speeding up YAMLs generation.
- `kustomize` (IF USED) is expected to be installed locally.
- `helm` (IF USED) is expected to be installed locally.
- `yamllint` (IF USED) is expected to be installed locally (https://github.com/adrienverge/yamllint).
- `kube-linter` (IF USED) is expected to be installed locally (https://github.com/stackrox/kube-linter).
### Configuration files (`config/*.yml`)
All configuration files are merged together at runtime and the following structure is expected:
```
envs:
<environment_name_1>:
apps:
<application_name_1>: {}
#<application_name_N>: {} ## additional applications for the environment
#<environment_name_N>: ## additional environments
vars:
<variable_name_1>: <variable_value_1>
#<variable_name_N>: <variable_value_N> ## additional variables
```
Application names must correspond to the relative paths from the source directory to the application directory, e.g., ```grafana```, ```path/to/grafana``` .
Example configuration file:
```tests/examples/app_types/config/config.yml```
### Source directory structure
Example directory structure:
```tests/examples/app_types/source/```
## Execution
```
python3 -m venv .venv
. .venv/bin/activate
pip install make-argocd-fly
```
```
usage: make-argocd-fly [-h] [--root-dir ROOT_DIR] [--config-file CONFIG_FILE] [--config-dir CONFIG_DIR] [--source-dir SOURCE_DIR] [--output-dir OUTPUT_DIR] [--tmp-dir TMP_DIR]
[--render-apps RENDER_APPS] [--render-envs RENDER_ENVS] [--skip-generate] [--preserve-tmp-dir] [--remove-output-dir] [--print-vars]
[--var-identifier VAR_IDENTIFIER] [--skip-latest-version-check] [--yaml-linter] [--kube-linter] [--loglevel LOGLEVEL] [--version]
Render ArgoCD Applications.
options:
-h, --help show this help message and exit
--root-dir ROOT_DIR Root directory (default: current directory)
--config-file CONFIG_FILE
Configuration file (default: config.yml) # DEPRECATED
--config-dir CONFIG_DIR
Configuration files directory (default: config)
--source-dir SOURCE_DIR
Source files directory (default: source)
--output-dir OUTPUT_DIR
Output files directory (default: output)
--tmp-dir TMP_DIR Temporary files directory (default: .tmp)
--render-apps RENDER_APPS
Comma separate list of applications to render
--render-envs RENDER_ENVS
Comma separate list of environments to render
--skip-generate Skip resource generation
--preserve-tmp-dir Preserve temporary directory
--remove-output-dir Remove output directory
--print-vars Print variables for each application
--var-identifier VAR_IDENTIFIER
Variable prefix in configuration files (default: $)
--skip-latest-version-check
Skip latest version check
--yaml-linter Run yamllint against output directory (https://github.com/adrienverge/yamllint)
--kube-linter Run kube-linter against output directory (https://github.com/stackrox/kube-linter)
--loglevel LOGLEVEL DEBUG, INFO, WARNING, ERROR, CRITICAL
--version Show version
```
## Advanced usage
### ArgoCD integration
The [ArgoCD app-of-apps pattern](https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/) is a method for deploying applications in a Kubernetes cluster. `make-argocd-fly` supports this pattern by generating ArgoCD `Application` resources for each application specified in the configuration file. These resources can be deployed in the cluster using ArgoCD, which will automatically handle the deployment of all applications referenced in the `Application` resources. The app-of-apps pattern supports nesting, enabling hierarchical organization of applications, where only the top-level application needs to be deployed manually.
To leverage the ArgoCD app-of-apps pattern in `make-argocd-fly`, specify the following variables and application parameters:
```
envs:
<environment_name>:
apps:
<bootstrap_application>: {} ## application that needs be deployed externally that will deploy other applications
<application_name>:
params:
parent_app: <bootstrap_application> ## (OPTIONAL) application that will deploy this application
parent_app_env: <environment_name> ## (OPTIONAL) environment name for the parent application, default: null
vars:
argocd:
namespace: <argocd_namespace> ## (OPTIONAL) namespace for ArgoCD `Application` resource, default: argocd
sync_wave: <application_sync_wave> ## (OPTIONAL) `sync_wave` annotation for ArgoCD `Application` resource
finalizers: <argocd_finalizers> ## (OPTIONAL) default: []
project: <project_name> ## (OPTIONAL) ArgoCD project name, default: default
source:
repo_url: <argocd_repo_url> ## URL to the Git repository
target_revision: <argocd_target_revision> ## target revision for the Git repository
directory:
recurse: <true|false> ## (OPTIONAL) not set by default
destination:
server: <kube_apiserver> ## kube-apiserver address
namespace: <namespace> ## (OPTIONAL) default namespace where the application resources will be deployed, default: argocd
sync_policy: <argocd_sync_policy> ## (OPTIONAL) default: {}
ignoreDifferences: <argocd_ignoreDifferences> ## (OPTIONAL) default: []
```
### Magic variables
The following variable names are reserved for internal purposes and must not be used in the configuration file:
- __application
The following variable are automatically populated and can be referenced without explicit definition:
- env_name
- app_name
### Variables scopes
Variables can be defined at three levels: root (global), per-environment, and per-application.
- Global variables (defined at the root level) are accessible by all applications.
- Environment-specific variables apply only to a specific environment but can be used by any application within that environment.
- Application-specific variables are restricted to the application in which they are defined.
If a variable is defined at multiple levels, the following priority rules apply: global < environment < application.
```
envs:
<environment_name>:
apps:
<application_name>:
vars:
<variable_name>: <variable_value>
vars:
<variable_name>: <variable_value>
vars:
<variable_name>: <variable_value>
```
In order to unset a key of a dictionary variable that is set at a higher level, use the `null` value:
```
envs:
<environment_name>:
vars:
<variable_name>:
<key>: null
vars:
<variable_name>:
<key>: <value>
```
### Variables in `config.yml`
Variables can be referenced in the configuration file using the following syntax:
- ```${var_name}```
- ```${var_name[dict_key][...]}```
Variables can also be embedded within strings:
- ```prefix-${var_name}-suffix```
### Jinja2 templates
All standard Jinja2 features are supported. For example, to render a Jinja2 template from a file in the current jinja2 template, use the following block:
```
{%- filter indent(width=4) %}
{% include 'files/file.json.j2' %}
{% endfilter %}
```
Extra Jinja2 extentsons/filters are available for use:
- `rawinclude` - to include literal file content (without rendering) in the current jinja2 template, use the following block:
```
{%- filter indent(width=4) %}
{% rawinclude 'files/file.json' %}
{% endfilter %}
```
- `include_map` - to render templates from a subdirectory as YAML key-value pairs (where file name would be the key and rendered file content would be the value), use the following block:
```
{%- filter indent(width=2) %}
{% include_map 'files/' %}
{% endfilter %}
```
- `rawinclude_map` - to include literal file content from a subdirectory as YAML key-value pairs (where file name would be the key and file content would be the value), use the following block:
```
{%- filter indent(width=2) %}
{% rawinclude_map 'files/' %}
{% endfilter %}
```
- `include_list` - to render templates from a subdirectory as YAML list (where list elements would be rendered file content), use the following block:
```
{%- filter indent(width=2) %}
{% include_list 'files/' %}
{% endfilter %}
```
- `rawinclude_list` - to include literal file content from a subdirectory as YAML list (where list elements would be file content), use the following block:
```
{%- filter indent(width=2) %}
{% rawinclude_list 'files/' %}
{% endfilter %}
```
- `file_list` - to render file names in a subdirectory as YAML list (where list elements would be file names), use the following block:
```
{%- filter indent(width=6) %}
{% file_list 'files/' [<prefix>] %}
{% endfilter %}
```
Note that there is an optional second parameter, which is a prefix that will be added to each file name in the list. This can be useful for constructing full paths or URLs.
- `dig` - to perform a DNS lookup, use the following filter:
```
{{ 'example.com' | dig }}
```
- Ansible filters are supported as well: https://pypi.org/project/jinja2-ansible-filters/
### Kustomize
Local files referenced in the `resources` section should be named following this convention: the Kubernetes resource type followed by an underscore (`_`) and the resource name. For example:
```
resources:
- deployment_nginx.yml
- serviceaccount_nginx-prod.yml
```
Example:
```tests/e2e/source/app_1```
When using Kustomize overlays, the base directory should be named `base`, and overlay directories should be named after the corresponding environment names.
Example:
```tests/e2e/source/app_2```
If using a Helm `values.yml` file, it must be named `values.yml` and placed within the application directory. Additionally, the file must be explicitly specified for rendering in the configuration file:
```
envs:
<environment_name>:
apps:
<application_name>:
params:
non_k8s_files_to_render: ['values.yml'] ## (OPTIONAL) list of files to render that are not Kubernetes resources (e.g., values.yml)
```
### Exclude certain directories
If there are certain files in the source application directory that you do not want to render, you can use the `exclude_rendering` parameter in your configuration to exclude them from the rendering process:
```
envs:
<environment_name>:
apps:
<application_name>:
params:
exclude_rendering: ['<directory>'] ## (OPTIONAL) list of directories to exclude from rendering (e.g., unit test files for opa)
```
## Caveats
- Comments are not rendered in the final output manifests.
## For developers
### Build instructions
https://setuptools.pypa.io/en/latest/userguide/quickstart.html
https://setuptools.pypa.io/en/latest/userguide/pyproject_config.html
https://setuptools.pypa.io/en/latest/userguide/datafiles.html
https://packaging.python.org/en/latest/tutorials/packaging-projects/
https://packaging.python.org/en/latest/guides/single-sourcing-package-version/#single-sourcing-the-version
https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/
### Preparation
```
python3 -m venv .venv
. .venv/bin/activate
python3 -m pip install --upgrade pip
pip install -r requirements.txt
pip install -r requirements.dev.txt
```
### Execution
```
python main.py --root-dir <path>
```
### Packaging
```
<tag HEAD>
python -m build
python -m twine upload dist/*
```
### Profiling
```
python -m cProfile -o profile.pstats main.py --root-dir <path>
gprof2dot log.pstats [-z <function>] | dot -Tsvg -o profile.svg
```
### Code coverage HTML report
```
python -m tox
```
Raw data
{
"_id": null,
"home_page": null,
"name": "make-argocd-fly",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.11",
"maintainer_email": null,
"keywords": "argocd, kustomize, jinja2",
"author": null,
"author_email": "Andrei Lapin <karandash8@gmail.com>",
"download_url": "https://files.pythonhosted.org/packages/8c/f1/996bf2cde22522afe578a020da2ce4f5105e85976b3939cd3419fda48fc2/make_argocd_fly-0.2.15.tar.gz",
"platform": null,
"description": "# make-argocd-fly\n [](https://img.shields.io/endpoint?url=https://gist.githubusercontent.com/Karandash8/26eb92c97bbfac22b938afebac85e7cd/raw/covbadge.json)\n\n## Description\n`make-argocd-fly` simplifies generation of Kubernetes manifests in multi-cluster and multi-application environments. It leverages YAML, Jinja2 templates, Kustomize files, and Helm charts through Kustomize, streamlining the process of creating and maintaining Kubernetes resources. Although the generated manifests can be deployed using any external tool, such as kubectl, `make-argocd-fly` provides native integration with ArgoCD, enhancing the overall deployment experience.\n\nWith `make-argocd-fly`, you can develop resources in various formats, specify deployment details in a configuration file, generate the final manifests effortlessly, and push them to a repository for ArgoCD to deploy to a Kubernetes cluster. This approach promotes transparency in what is being deployed and where, simplifies both maintenance and development, and assists in debugging issues.\n\n## Features\n- **ArgoCD App-of-Apps Pattern Support:** Native support for the app-of-apps pattern to organize complex applications, with automatic generation of ArgoCD `Application` resources for streamlined deployment.\n- **Jinja2 and Kustomize Rendering:** Effortlessly render Kubernetes manifests using Jinja2 templates and Kustomize, including support for Helm charts.\n- **Extended Jinja2 Functionality:** Includes additional Jinja2 extensions and filters, such as `include_raw`, to render content from external files.\n- **Flexible Variable Management:** Manage global, per-environment, and per-application Jinja2 variables, with support for referencing other variables.\n- **Subdirectory Resource Management:** Organize resources within subdirectories for improved structure and management.\n\n## How to start\n### Prerequisites\n- `libyaml` is expected to be installed locally for speeding up YAMLs generation.\n- `kustomize` (IF USED) is expected to be installed locally.\n- `helm` (IF USED) is expected to be installed locally.\n- `yamllint` (IF USED) is expected to be installed locally (https://github.com/adrienverge/yamllint).\n- `kube-linter` (IF USED) is expected to be installed locally (https://github.com/stackrox/kube-linter).\n\n### Configuration files (`config/*.yml`)\nAll configuration files are merged together at runtime and the following structure is expected:\n```\nenvs:\n <environment_name_1>:\n apps:\n <application_name_1>: {}\n #<application_name_N>: {} ## additional applications for the environment\n #<environment_name_N>: ## additional environments\n\nvars:\n <variable_name_1>: <variable_value_1>\n #<variable_name_N>: <variable_value_N> ## additional variables\n```\n\nApplication names must correspond to the relative paths from the source directory to the application directory, e.g., ```grafana```, ```path/to/grafana``` .\n\nExample configuration file:\n```tests/examples/app_types/config/config.yml```\n\n### Source directory structure\nExample directory structure:\n```tests/examples/app_types/source/```\n\n## Execution\n```\npython3 -m venv .venv\n. .venv/bin/activate\npip install make-argocd-fly\n```\n\n```\nusage: make-argocd-fly [-h] [--root-dir ROOT_DIR] [--config-file CONFIG_FILE] [--config-dir CONFIG_DIR] [--source-dir SOURCE_DIR] [--output-dir OUTPUT_DIR] [--tmp-dir TMP_DIR]\n [--render-apps RENDER_APPS] [--render-envs RENDER_ENVS] [--skip-generate] [--preserve-tmp-dir] [--remove-output-dir] [--print-vars]\n [--var-identifier VAR_IDENTIFIER] [--skip-latest-version-check] [--yaml-linter] [--kube-linter] [--loglevel LOGLEVEL] [--version]\n\nRender ArgoCD Applications.\n\noptions:\n -h, --help show this help message and exit\n --root-dir ROOT_DIR Root directory (default: current directory)\n --config-file CONFIG_FILE\n Configuration file (default: config.yml) # DEPRECATED\n --config-dir CONFIG_DIR\n Configuration files directory (default: config)\n --source-dir SOURCE_DIR\n Source files directory (default: source)\n --output-dir OUTPUT_DIR\n Output files directory (default: output)\n --tmp-dir TMP_DIR Temporary files directory (default: .tmp)\n --render-apps RENDER_APPS\n Comma separate list of applications to render\n --render-envs RENDER_ENVS\n Comma separate list of environments to render\n --skip-generate Skip resource generation\n --preserve-tmp-dir Preserve temporary directory\n --remove-output-dir Remove output directory\n --print-vars Print variables for each application\n --var-identifier VAR_IDENTIFIER\n Variable prefix in configuration files (default: $)\n --skip-latest-version-check\n Skip latest version check\n --yaml-linter Run yamllint against output directory (https://github.com/adrienverge/yamllint)\n --kube-linter Run kube-linter against output directory (https://github.com/stackrox/kube-linter)\n --loglevel LOGLEVEL DEBUG, INFO, WARNING, ERROR, CRITICAL\n --version Show version\n```\n\n## Advanced usage\n### ArgoCD integration\nThe [ArgoCD app-of-apps pattern](https://argo-cd.readthedocs.io/en/stable/operator-manual/cluster-bootstrapping/) is a method for deploying applications in a Kubernetes cluster. `make-argocd-fly` supports this pattern by generating ArgoCD `Application` resources for each application specified in the configuration file. These resources can be deployed in the cluster using ArgoCD, which will automatically handle the deployment of all applications referenced in the `Application` resources. The app-of-apps pattern supports nesting, enabling hierarchical organization of applications, where only the top-level application needs to be deployed manually.\n\nTo leverage the ArgoCD app-of-apps pattern in `make-argocd-fly`, specify the following variables and application parameters:\n\n```\nenvs:\n <environment_name>:\n apps:\n <bootstrap_application>: {} ## application that needs be deployed externally that will deploy other applications\n <application_name>:\n params:\n parent_app: <bootstrap_application> ## (OPTIONAL) application that will deploy this application\n parent_app_env: <environment_name> ## (OPTIONAL) environment name for the parent application, default: null\nvars:\n argocd:\n namespace: <argocd_namespace> ## (OPTIONAL) namespace for ArgoCD `Application` resource, default: argocd\n sync_wave: <application_sync_wave> ## (OPTIONAL) `sync_wave` annotation for ArgoCD `Application` resource\n finalizers: <argocd_finalizers> ## (OPTIONAL) default: []\n project: <project_name> ## (OPTIONAL) ArgoCD project name, default: default\n source:\n repo_url: <argocd_repo_url> ## URL to the Git repository\n target_revision: <argocd_target_revision> ## target revision for the Git repository\n directory:\n recurse: <true|false> ## (OPTIONAL) not set by default\n destination:\n server: <kube_apiserver> ## kube-apiserver address\n namespace: <namespace> ## (OPTIONAL) default namespace where the application resources will be deployed, default: argocd\n sync_policy: <argocd_sync_policy> ## (OPTIONAL) default: {}\n ignoreDifferences: <argocd_ignoreDifferences> ## (OPTIONAL) default: []\n```\n\n### Magic variables\nThe following variable names are reserved for internal purposes and must not be used in the configuration file:\n- __application\n\nThe following variable are automatically populated and can be referenced without explicit definition:\n- env_name\n- app_name\n\n### Variables scopes\nVariables can be defined at three levels: root (global), per-environment, and per-application.\n\n- Global variables (defined at the root level) are accessible by all applications.\n- Environment-specific variables apply only to a specific environment but can be used by any application within that environment.\n- Application-specific variables are restricted to the application in which they are defined.\n\nIf a variable is defined at multiple levels, the following priority rules apply: global < environment < application.\n\n\n```\nenvs:\n <environment_name>:\n apps:\n <application_name>:\n vars:\n <variable_name>: <variable_value>\n vars:\n <variable_name>: <variable_value>\nvars:\n <variable_name>: <variable_value>\n```\n\nIn order to unset a key of a dictionary variable that is set at a higher level, use the `null` value:\n```\nenvs:\n <environment_name>:\n vars:\n <variable_name>:\n <key>: null\nvars:\n <variable_name>:\n <key>: <value>\n```\n\n### Variables in `config.yml`\nVariables can be referenced in the configuration file using the following syntax:\n- ```${var_name}```\n- ```${var_name[dict_key][...]}```\n\nVariables can also be embedded within strings:\n- ```prefix-${var_name}-suffix```\n\n### Jinja2 templates\nAll standard Jinja2 features are supported. For example, to render a Jinja2 template from a file in the current jinja2 template, use the following block:\n```\n{%- filter indent(width=4) %}\n{% include 'files/file.json.j2' %}\n{% endfilter %}\n```\n\nExtra Jinja2 extentsons/filters are available for use:\n- `rawinclude` - to include literal file content (without rendering) in the current jinja2 template, use the following block:\n ```\n {%- filter indent(width=4) %}\n {% rawinclude 'files/file.json' %}\n {% endfilter %}\n ```\n- `include_map` - to render templates from a subdirectory as YAML key-value pairs (where file name would be the key and rendered file content would be the value), use the following block:\n ```\n {%- filter indent(width=2) %}\n {% include_map 'files/' %}\n {% endfilter %}\n ```\n\n- `rawinclude_map` - to include literal file content from a subdirectory as YAML key-value pairs (where file name would be the key and file content would be the value), use the following block:\n ```\n {%- filter indent(width=2) %}\n {% rawinclude_map 'files/' %}\n {% endfilter %}\n ```\n\n- `include_list` - to render templates from a subdirectory as YAML list (where list elements would be rendered file content), use the following block:\n ```\n {%- filter indent(width=2) %}\n {% include_list 'files/' %}\n {% endfilter %}\n ```\n\n- `rawinclude_list` - to include literal file content from a subdirectory as YAML list (where list elements would be file content), use the following block:\n ```\n {%- filter indent(width=2) %}\n {% rawinclude_list 'files/' %}\n {% endfilter %}\n ```\n\n- `file_list` - to render file names in a subdirectory as YAML list (where list elements would be file names), use the following block:\n ```\n {%- filter indent(width=6) %}\n {% file_list 'files/' [<prefix>] %}\n {% endfilter %}\n ```\n Note that there is an optional second parameter, which is a prefix that will be added to each file name in the list. This can be useful for constructing full paths or URLs.\n\n- `dig` - to perform a DNS lookup, use the following filter:\n ```\n {{ 'example.com' | dig }}\n ```\n\n- Ansible filters are supported as well: https://pypi.org/project/jinja2-ansible-filters/\n\n### Kustomize\nLocal files referenced in the `resources` section should be named following this convention: the Kubernetes resource type followed by an underscore (`_`) and the resource name. For example:\n```\nresources:\n - deployment_nginx.yml\n - serviceaccount_nginx-prod.yml\n```\n\nExample:\n```tests/e2e/source/app_1```\n\nWhen using Kustomize overlays, the base directory should be named `base`, and overlay directories should be named after the corresponding environment names.\nExample:\n```tests/e2e/source/app_2```\n\nIf using a Helm `values.yml` file, it must be named `values.yml` and placed within the application directory. Additionally, the file must be explicitly specified for rendering in the configuration file:\n```\nenvs:\n <environment_name>:\n apps:\n <application_name>:\n params:\n non_k8s_files_to_render: ['values.yml'] ## (OPTIONAL) list of files to render that are not Kubernetes resources (e.g., values.yml)\n```\n### Exclude certain directories\nIf there are certain files in the source application directory that you do not want to render, you can use the `exclude_rendering` parameter in your configuration to exclude them from the rendering process:\n```\nenvs:\n <environment_name>:\n apps:\n <application_name>:\n params:\n exclude_rendering: ['<directory>'] ## (OPTIONAL) list of directories to exclude from rendering (e.g., unit test files for opa)\n```\n\n## Caveats\n- Comments are not rendered in the final output manifests.\n\n## For developers\n### Build instructions\nhttps://setuptools.pypa.io/en/latest/userguide/quickstart.html\nhttps://setuptools.pypa.io/en/latest/userguide/pyproject_config.html\nhttps://setuptools.pypa.io/en/latest/userguide/datafiles.html\nhttps://packaging.python.org/en/latest/tutorials/packaging-projects/\nhttps://packaging.python.org/en/latest/guides/single-sourcing-package-version/#single-sourcing-the-version\nhttps://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/\n\n### Preparation\n```\npython3 -m venv .venv\n. .venv/bin/activate\npython3 -m pip install --upgrade pip\npip install -r requirements.txt\npip install -r requirements.dev.txt\n```\n\n### Execution\n```\npython main.py --root-dir <path>\n```\n\n### Packaging\n```\n<tag HEAD>\npython -m build\npython -m twine upload dist/*\n```\n\n### Profiling\n```\npython -m cProfile -o profile.pstats main.py --root-dir <path>\ngprof2dot log.pstats [-z <function>] | dot -Tsvg -o profile.svg\n```\n\n### Code coverage HTML report\n```\npython -m tox\n```\n",
"bugtrack_url": null,
"license": null,
"summary": "A tool to generate Kubernetes manifests from templates",
"version": "0.2.15",
"project_urls": {
"Source Code": "https://github.com/Karandash8/make-argocd-fly"
},
"split_keywords": [
"argocd",
" kustomize",
" jinja2"
],
"urls": [
{
"comment_text": null,
"digests": {
"blake2b_256": "d8deca2e2de948e66c1e9af9e50f379e0974850bae3657719e99524925d9ab15",
"md5": "52cf573f4277096dd089664fe134415d",
"sha256": "fb91e88796c3490626ba6fc379e3fcb2ace360868e4564c2f7717cbe6c537973"
},
"downloads": -1,
"filename": "make_argocd_fly-0.2.15-py3-none-any.whl",
"has_sig": false,
"md5_digest": "52cf573f4277096dd089664fe134415d",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.11",
"size": 138675,
"upload_time": "2025-07-15T19:01:55",
"upload_time_iso_8601": "2025-07-15T19:01:55.960210Z",
"url": "https://files.pythonhosted.org/packages/d8/de/ca2e2de948e66c1e9af9e50f379e0974850bae3657719e99524925d9ab15/make_argocd_fly-0.2.15-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": null,
"digests": {
"blake2b_256": "8cf1996bf2cde22522afe578a020da2ce4f5105e85976b3939cd3419fda48fc2",
"md5": "2d506c5a0837778e189ceeda9422a903",
"sha256": "64e025ddb4d8b59024db957af9351bdf88bc9d3e39135a54e991efd3601db823"
},
"downloads": -1,
"filename": "make_argocd_fly-0.2.15.tar.gz",
"has_sig": false,
"md5_digest": "2d506c5a0837778e189ceeda9422a903",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.11",
"size": 76468,
"upload_time": "2025-07-15T19:01:57",
"upload_time_iso_8601": "2025-07-15T19:01:57.543534Z",
"url": "https://files.pythonhosted.org/packages/8c/f1/996bf2cde22522afe578a020da2ce4f5105e85976b3939cd3419fda48fc2/make_argocd_fly-0.2.15.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2025-07-15 19:01:57",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "Karandash8",
"github_project": "make-argocd-fly",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"requirements": [
{
"name": "PyYAML",
"specs": [
[
"==",
"6.0.2"
]
]
},
{
"name": "Jinja2",
"specs": [
[
"==",
"3.1.6"
]
]
},
{
"name": "jinja2-ansible-filters",
"specs": [
[
"==",
"1.3.2"
]
]
},
{
"name": "yamllint",
"specs": [
[
"==",
"1.37.0"
]
]
},
{
"name": "packaging",
"specs": [
[
"==",
"24.2"
]
]
},
{
"name": "Deprecated",
"specs": [
[
"==",
"1.2.18"
]
]
}
],
"tox": true,
"lcname": "make-argocd-fly"
}
JSON
