leverage 1.12.1__tar.gz → 1.12.2__tar.gz

leverage-1.12.2/PKG-INFO

@@ -0,0 +1,279 @@
+Metadata-Version: 2.1
+Name: leverage
+Version: 1.12.2
+Summary: Binbash Leverage Command-Line tool.
+Home-page: https://github.com/binbashar/leverage
+License: MIT
+Keywords: leverage,binbash
+Author: BinBash Inc
+Author-email: leverage@binbash.com.ar
+Requires-Python: >=3.8,<3.12
+Classifier: Development Status :: 5 - Production/Stable
+Classifier: Intended Audience :: Developers
+Classifier: License :: OSI Approved :: MIT License
+Classifier: Programming Language :: Python :: 3
+Classifier: Programming Language :: Python :: 3.8
+Classifier: Programming Language :: Python :: 3.9
+Classifier: Programming Language :: Python :: 3.10
+Classifier: Programming Language :: Python :: 3.11
+Classifier: Topic :: Software Development :: Build Tools
+Requires-Dist: boto3 (==1.33.2)
+Requires-Dist: click (==8.0.1)
+Requires-Dist: configupdater (==3.2)
+Requires-Dist: docker (==6.1.0)
+Requires-Dist: dockerpty (==0.4.1)
+Requires-Dist: docutils (==0.17.1)
+Requires-Dist: jinja2 (==3.0.1)
+Requires-Dist: python-hcl2 (==3.0.1)
+Requires-Dist: questionary (==1.10.0)
+Requires-Dist: rich (==10.4.0)
+Requires-Dist: ruamel.yaml (==0.17.10)
+Requires-Dist: yaenv (==1.4.1)
+Project-URL: Documentation, https://leverage.binbash.co/
+Project-URL: Repository, https://github.com/binbashar/leverage
+Description-Content-Type: text/markdown
+
+<a href="https://github.com/binbashar">
+    <img src="https://raw.githubusercontent.com/binbashar/le-ref-architecture-doc/master/docs/assets/images/logos/binbash-leverage-banner.png" width="1032" align="left" alt="Binbash"/>
+</a>
+<br clear="left"/>
+
+# Leverage CLI
+
+Leverage CLI is the tool used to manage and interact with any Leverage project.
+
+It transparently handles the most complex and error prone tasks that arise from working with a state-of-the-art
+infrastructure definition like our Leverage Reference Architecture. Leverage CLI uses a dockerized approach to
+encapsulate the tools needed to perform such tasks and to free the user from having to deal with the configuration and
+management of said tools.
+Provides the means to interact with your Leverage project and allows you to define custom tasks to run.
+
+Reviewing and implementing the [Binbash Leverage Landing Zone for AWS](https://leverage.binbash.co/try-leverage/) would
+be a very good place to start!
+
+## Documentation
+
+For installation instructions and all documentation regarding Leverage CLI, please refer
+to [this page](https://leverage.binbash.co/user-guide/leverage-cli/installation/).
+
+### Note for migration from previous versions
+
+If you come from Leverage CLI version <1.8.0 and want to install Leverage CLI version >= 1.8.0 keep into account the
+following.
+
+The `build.env` file format has changed. As an example, this is the old format:
+
+```
+# Project settings
+PROJECT=bb
+
+# General
+MFA_ENABLED=false
+
+# Terraform
+TERRAFORM_IMAGE_NAME=binbash/terraform-awscli-slim
+TERRAFORM_IMAGE_TAG=1.1.9
+```
+
+New version example:
+
+```
+# Project settings
+PROJECT=bb
+
+# General
+MFA_ENABLED=false
+
+# Terraform
+TERRAFORM_IMAGE_TAG=1.2.7-0.1.0
+```
+
+So, if you have created a project with version <1.8.0 and want to use it with version >=1.8.0 you should:
+
+- remove TERRAFORM_IMAGE_NAME line
+- update TERRAFORM_IMAGE_TAG from this form '9.9.9' to this one '9.9.9-9.9.9'.
+
+For the second item you can check the version [here](https://hub.docker.com/r/binbash/leverage-toolbox/tags).
+
+## System requirements
+
+### Supported python versions
+
+Leverage CLI explicitly supports the following Python versions:
+
+- Python 3.8.x
+- Python 3.9.x
+- Python 3.10.x
+- Python 3.11.x
+
+These versions are not only supported but are also the only versions used in our CI/CD pipelines to ensure compatibility
+and performance. This rigorous testing helps prevent compatibility issues and ensures that the Leverage CLI performs as
+expected under these versions.
+
+Please ensure that your development and deployment environments are set up with one of these supported versions. Our
+GitHub Actions and other CI workflows are specifically configured to test against these Python versions, which
+reinforces our commitment to maintaining a reliable and stable toolset.
+
+### Installing multiple python versions with pyenv
+
+If you need to install one of the supported Python versions (3.8, 3.9, 3.10 or 3.11) and would like to manage multiple
+Python environments, `pyenv` is a highly recommended tool. Here’s how you can use `pyenv` to install and manage Python
+versions:
+
+1. Installing Pyenv:
+
+```bash
+curl https://pyenv.run | bash
+```
+
+2. Add Pyenv to your shell to automate the setup process (if using bash, otherwise you can find details on how to set it
+   up [here](https://github.com/pyenv/pyenv#set-up-your-shell-environment-for-pyenv)):
+
+```bash
+echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
+echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
+echo 'eval "$(pyenv init --path)"' >> ~/.bashrc
+echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.bashrc
+exec "$SHELL"
+```
+
+3. Installing python versions:
+
+Once pyenv is installed, you can install any supported Python version by following these steps:
+
+```bash
+pyenv install 3.8.10
+pyenv install 3.9.7
+pyenv install 3.10.1
+pyenv install 3.11.8
+```
+
+4. Create a virtual environment for the leverage project:
+
+Create a virtual environment for your project using Python 3.9.7:
+
+```bash
+pyenv virtualenv 3.9.7 leverage_py_39_venv
+```
+
+5. Set your virtual environment to be used in the project:
+
+To set this virtual environment as the local environment for your project, navigate to your project directory and run:
+
+```bash
+cd <path_to_leverage_project_root>
+pyenv local leverage_py_39_venv
+```
+
+This setup commands `pyenv` to use `leverage_py_39_venv` as the local Python version for your project directory,
+ensuring that all Python operations within this directory use this isolated environment.
+
+## Setting up development environment
+
+Before you begin, ensure you are running Python 3.8, 3.9, or 3.10 as these are the only versions Leverage CLI supports
+and tests against.
+
+We now use Poetry for dependency management. Setup your development environment as follows:
+
+1. Install Poetry:
+
+```bash
+curl -sSL https://install.python-poetry.org | POETRY_VERSION=1.8.2 python -
+```
+
+2. Clone the repository and navigate into it:
+
+```bash
+git clone https://github.com/binbashar/leverage.git
+cd leverage
+```
+
+3. Install dependencies using Poetry:
+
+```bash
+poetry install --with=dev --with=main
+```
+
+4. To activate the virtual environment and start using the CLI in dev mode, use:
+
+```bash
+poetry shell
+```
+
+## Pre-commit hooks
+
+In order to run black automatically on every commit, you should install `pre-commit` first:
+
+https://pre-commit.com/#installation
+
+And then the hooks:
+
+```
+poetry run pre-commit install
+```
+
+## Running Tests
+
+To run unit tests, pytest is the tool of choice, and the required dependencies are available in the
+corresponding `dev-requirements.txt`.
+
+Integration tests are implemented using [bats](https://github.com/bats-core/bats-core/). Bear in mind that bats tests
+are meant to be run in a throwaway environment since they perform filesystem manipulations and installation and removal
+of packages, and the cleanup may not be completely thorough. As such, is highly recommended to run these tests using the
+docker image.
+
+### Manually
+
+1. Unit tests:
+
+```bash
+poetry run pytest
+```
+
+2. Integration tests:
+
+Install dependencies (MacOS):
+
+```bash
+brew install bats-core
+brew tap bats-core/bats-core
+brew install bats-support
+brew install bats-assert
+```
+
+```bash
+bats -r tests/bats
+```
+
+### Using docker image
+
+A Docker image suitable for running all tests can be crafted by running `make build-image`. After crafting the image all
+tests can be executed.
+
+To run all tests, run `make tests`. Alternatively `make test-unit` or `make test-int` for unit or integration tests
+respectively.
+
+## Release Process
+
+* On every PR, a Github Action workflow is triggered to create/update a release draft.
+* The version number is determined by the labels of those PRs (major, minor, fix).
+* The release draft has to be manually published. This allows for any number of PR (features, fixes) to make the cut.
+* Once a release is published, another workflow is triggered to create and push the package to PyPi.
+
+## Release Candidate Process
+
+* There is an Action called "Test Build Package and Push".
+* This Action can be called manually on any branch specifying the version to release to test.
+    * The version is a Release Candidate following the Semver: e.g. if the next release is 1.2.3, the test version
+      should be 1.2.3-rc.1
+* The package will be published to [PyPi](https://pypi.org/project/leverage/).
+
+## Contributors/Contributing
+
+* Leverage CLI was initially based on Pynt: https://github.com/rags/pynt
+
+## License
+
+Leverage CLI is licensed
+under [MIT license](http://opensource.org/licenses/MIT)[BinBash Inc](https://github.com/binbashar)
+

leverage-1.12.2/README.md

@@ -0,0 +1,243 @@
+<a href="https://github.com/binbashar">
+    <img src="https://raw.githubusercontent.com/binbashar/le-ref-architecture-doc/master/docs/assets/images/logos/binbash-leverage-banner.png" width="1032" align="left" alt="Binbash"/>
+</a>
+<br clear="left"/>
+
+# Leverage CLI
+
+Leverage CLI is the tool used to manage and interact with any Leverage project.
+
+It transparently handles the most complex and error prone tasks that arise from working with a state-of-the-art
+infrastructure definition like our Leverage Reference Architecture. Leverage CLI uses a dockerized approach to
+encapsulate the tools needed to perform such tasks and to free the user from having to deal with the configuration and
+management of said tools.
+Provides the means to interact with your Leverage project and allows you to define custom tasks to run.
+
+Reviewing and implementing the [Binbash Leverage Landing Zone for AWS](https://leverage.binbash.co/try-leverage/) would
+be a very good place to start!
+
+## Documentation
+
+For installation instructions and all documentation regarding Leverage CLI, please refer
+to [this page](https://leverage.binbash.co/user-guide/leverage-cli/installation/).
+
+### Note for migration from previous versions
+
+If you come from Leverage CLI version <1.8.0 and want to install Leverage CLI version >= 1.8.0 keep into account the
+following.
+
+The `build.env` file format has changed. As an example, this is the old format:
+
+```
+# Project settings
+PROJECT=bb
+
+# General
+MFA_ENABLED=false
+
+# Terraform
+TERRAFORM_IMAGE_NAME=binbash/terraform-awscli-slim
+TERRAFORM_IMAGE_TAG=1.1.9
+```
+
+New version example:
+
+```
+# Project settings
+PROJECT=bb
+
+# General
+MFA_ENABLED=false
+
+# Terraform
+TERRAFORM_IMAGE_TAG=1.2.7-0.1.0
+```
+
+So, if you have created a project with version <1.8.0 and want to use it with version >=1.8.0 you should:
+
+- remove TERRAFORM_IMAGE_NAME line
+- update TERRAFORM_IMAGE_TAG from this form '9.9.9' to this one '9.9.9-9.9.9'.
+
+For the second item you can check the version [here](https://hub.docker.com/r/binbash/leverage-toolbox/tags).
+
+## System requirements
+
+### Supported python versions
+
+Leverage CLI explicitly supports the following Python versions:
+
+- Python 3.8.x
+- Python 3.9.x
+- Python 3.10.x
+- Python 3.11.x
+
+These versions are not only supported but are also the only versions used in our CI/CD pipelines to ensure compatibility
+and performance. This rigorous testing helps prevent compatibility issues and ensures that the Leverage CLI performs as
+expected under these versions.
+
+Please ensure that your development and deployment environments are set up with one of these supported versions. Our
+GitHub Actions and other CI workflows are specifically configured to test against these Python versions, which
+reinforces our commitment to maintaining a reliable and stable toolset.
+
+### Installing multiple python versions with pyenv
+
+If you need to install one of the supported Python versions (3.8, 3.9, 3.10 or 3.11) and would like to manage multiple
+Python environments, `pyenv` is a highly recommended tool. Here’s how you can use `pyenv` to install and manage Python
+versions:
+
+1. Installing Pyenv:
+
+```bash
+curl https://pyenv.run | bash
+```
+
+2. Add Pyenv to your shell to automate the setup process (if using bash, otherwise you can find details on how to set it
+   up [here](https://github.com/pyenv/pyenv#set-up-your-shell-environment-for-pyenv)):
+
+```bash
+echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bashrc
+echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bashrc
+echo 'eval "$(pyenv init --path)"' >> ~/.bashrc
+echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.bashrc
+exec "$SHELL"
+```
+
+3. Installing python versions:
+
+Once pyenv is installed, you can install any supported Python version by following these steps:
+
+```bash
+pyenv install 3.8.10
+pyenv install 3.9.7
+pyenv install 3.10.1
+pyenv install 3.11.8
+```
+
+4. Create a virtual environment for the leverage project:
+
+Create a virtual environment for your project using Python 3.9.7:
+
+```bash
+pyenv virtualenv 3.9.7 leverage_py_39_venv
+```
+
+5. Set your virtual environment to be used in the project:
+
+To set this virtual environment as the local environment for your project, navigate to your project directory and run:
+
+```bash
+cd <path_to_leverage_project_root>
+pyenv local leverage_py_39_venv
+```
+
+This setup commands `pyenv` to use `leverage_py_39_venv` as the local Python version for your project directory,
+ensuring that all Python operations within this directory use this isolated environment.
+
+## Setting up development environment
+
+Before you begin, ensure you are running Python 3.8, 3.9, or 3.10 as these are the only versions Leverage CLI supports
+and tests against.
+
+We now use Poetry for dependency management. Setup your development environment as follows:
+
+1. Install Poetry:
+
+```bash
+curl -sSL https://install.python-poetry.org | POETRY_VERSION=1.8.2 python -
+```
+
+2. Clone the repository and navigate into it:
+
+```bash
+git clone https://github.com/binbashar/leverage.git
+cd leverage
+```
+
+3. Install dependencies using Poetry:
+
+```bash
+poetry install --with=dev --with=main
+```
+
+4. To activate the virtual environment and start using the CLI in dev mode, use:
+
+```bash
+poetry shell
+```
+
+## Pre-commit hooks
+
+In order to run black automatically on every commit, you should install `pre-commit` first:
+
+https://pre-commit.com/#installation
+
+And then the hooks:
+
+```
+poetry run pre-commit install
+```
+
+## Running Tests
+
+To run unit tests, pytest is the tool of choice, and the required dependencies are available in the
+corresponding `dev-requirements.txt`.
+
+Integration tests are implemented using [bats](https://github.com/bats-core/bats-core/). Bear in mind that bats tests
+are meant to be run in a throwaway environment since they perform filesystem manipulations and installation and removal
+of packages, and the cleanup may not be completely thorough. As such, is highly recommended to run these tests using the
+docker image.
+
+### Manually
+
+1. Unit tests:
+
+```bash
+poetry run pytest
+```
+
+2. Integration tests:
+
+Install dependencies (MacOS):
+
+```bash
+brew install bats-core
+brew tap bats-core/bats-core
+brew install bats-support
+brew install bats-assert
+```
+
+```bash
+bats -r tests/bats
+```
+
+### Using docker image
+
+A Docker image suitable for running all tests can be crafted by running `make build-image`. After crafting the image all
+tests can be executed.
+
+To run all tests, run `make tests`. Alternatively `make test-unit` or `make test-int` for unit or integration tests
+respectively.
+
+## Release Process
+
+* On every PR, a Github Action workflow is triggered to create/update a release draft.
+* The version number is determined by the labels of those PRs (major, minor, fix).
+* The release draft has to be manually published. This allows for any number of PR (features, fixes) to make the cut.
+* Once a release is published, another workflow is triggered to create and push the package to PyPi.
+
+## Release Candidate Process
+
+* There is an Action called "Test Build Package and Push".
+* This Action can be called manually on any branch specifying the version to release to test.
+    * The version is a Release Candidate following the Semver: e.g. if the next release is 1.2.3, the test version
+      should be 1.2.3-rc.1
+* The package will be published to [PyPi](https://pypi.org/project/leverage/).
+
+## Contributors/Contributing
+
+* Leverage CLI was initially based on Pynt: https://github.com/rags/pynt
+
+## License
+
+Leverage CLI is licensed
+under [MIT license](http://opensource.org/licenses/MIT)[BinBash Inc](https://github.com/binbashar)

{leverage-1.12.1 → leverage-1.12.2}/leverage/__init__.py

@@ -3,7 +3,7 @@
 """
 # pylint: disable=wrong-import-position
 
-__version__ = "1.12.1"
+__version__ = "1.12.2"
 __toolbox_version__ = "1.2.7-0.1.12"
 
 import sys

{leverage-1.12.1 → leverage-1.12.2}/leverage/leverage.py

@@ -9,7 +9,8 @@ from leverage.tasks import list_tasks as _list_tasks
 from leverage._internals import pass_state
 
 from leverage.modules.aws import aws
-from leverage.modules import run, project, terraform, credentials, tfautomv, kubectl, shell
+from leverage.modules.credentials import credentials
+from leverage.modules import run, project, terraform, tfautomv, kubectl, shell
 
 
 @click.group(invoke_without_command=True)

{leverage-1.12.1 → leverage-1.12.2}/leverage/modules/__init__.py

@@ -1,7 +1,6 @@
 from .run import run
 from .project import project
 from .terraform import terraform
-from .credentials import credentials
 from .tfautomv import tfautomv
 from .kubectl import kubectl
 from .shell import shell

{leverage-1.12.1 → leverage-1.12.2}/leverage/modules/aws.py

@@ -202,15 +202,6 @@ def sso(context, cli, args):
 @pass_container
 def login(cli):
     """Login"""
-    # only from account or layer directories
-    # when to fail:
-    # - when this cond meets:
-    #   - no account dir
-    #   - no layer dir
-    if not cli.paths.get_location_type() in ["account", "layer", "layers-group"]:
-        logger.error("SSO configuration can only be performed at [bold]layer[/bold] or [bold]account[/bold] level.")
-        raise Exit(1)
-
     exit_code, region = cli.exec(f"configure get sso_region --profile {cli.project}-sso")
     if exit_code:
         logger.error(f"Region configuration for [bold]{cli.project}-sso[/bold] profile not found.")

{leverage-1.12.1 → leverage-1.12.2}/leverage/modules/credentials.py

@@ -1,27 +1,27 @@
 """
     Credentials managing module.
 """
-import re
 import csv
 import json
-from pathlib import Path
+import re
 from functools import wraps
+from pathlib import Path
 
 import click
-from click.exceptions import Exit
 import questionary
+from click.exceptions import Exit
 from questionary import Choice
 from ruamel.yaml import YAML
 
 from leverage import __toolbox_version__
 from leverage import logger
-from leverage.path import get_root_path
-from leverage.path import get_global_config_path
-from leverage.path import NotARepositoryError
 from leverage._internals import pass_state
-from leverage.container import get_docker_client
+from leverage._utils import ExitError
 from leverage.container import AWSCLIContainer
-
+from leverage.container import get_docker_client
+from leverage.path import NotARepositoryError
+from leverage.path import get_global_config_path
+from leverage.path import get_project_root_or_current_dir_path
 
 # Regexes for general validation
 PROJECT_SHORT = r"[a-z]{2,4}"
@@ -37,11 +37,11 @@ ACCOUNT_ID = r"[0-9]{12}"
 MFA_SERIAL = rf"arn:aws:iam::{ACCOUNT_ID}:mfa/{USERNAME}"
 
 # TODO: Remove these and get them into the global app state
+PROJECT_ROOT = get_project_root_or_current_dir_path()
 try:
     PROJECT_COMMON_TFVARS = Path(get_global_config_path())
-    PROJECT_ROOT = Path(get_root_path())
 except NotARepositoryError:
-    PROJECT_COMMON_TFVARS = PROJECT_ROOT = Path.cwd()
+    PROJECT_COMMON_TFVARS = Path.cwd()
 
 PROJECT_COMMON_TFVARS_FILE = "common.tfvars"
 PROJECT_COMMON_TFVARS = PROJECT_COMMON_TFVARS / PROJECT_COMMON_TFVARS_FILE
@@ -446,8 +446,7 @@ def configure_credentials(profile, file=None, make_backup=False):
     for key, value in values.items():
         exit_code, output = AWSCLI.exec(f"configure set {key} {value}", profile)
         if exit_code:
-            logger.error(f"AWS CLI error: {output}")
-            raise Exit(exit_code)
+            raise ExitError(exit_code, f"AWS CLI error: {output}")
 
 
 def _credentials_are_valid(profile):
@@ -481,8 +480,7 @@ def _get_management_account_id(profile):
     """
     exit_code, caller_identity = AWSCLI.exec("--output json sts get-caller-identity", profile)
     if exit_code:
-        logger.error(f"AWS CLI error: {caller_identity}")
-        raise Exit(exit_code)
+        raise ExitError(exit_code, f"AWS CLI error: {caller_identity}")
 
     caller_identity = json.loads(caller_identity)
     return caller_identity["Account"]
@@ -526,8 +524,7 @@ def _get_mfa_serial(profile):
     """
     exit_code, mfa_devices = AWSCLI.exec("--output json iam list-mfa-devices", profile)
     if exit_code:
-        logger.error(f"AWS CLI error: {mfa_devices}")
-        raise Exit(exit_code)
+        raise ExitError(exit_code, f"AWS CLI error: {mfa_devices}")
     mfa_devices = json.loads(mfa_devices)
 
     # Either zero or one MFA device should be configured for either `management` or `security` accounts users.
@@ -554,8 +551,7 @@ def configure_profile(profile, values):
     for key, value in values.items():
         exit_code, output = AWSCLI.exec(f"configure set {key} {value}", profile)
         if exit_code:
-            logger.error(f"AWS CLI error: {output}")
-            raise Exit(exit_code)
+            raise ExitError(exit_code, f"AWS CLI error: {output}")
 
 
 def configure_accounts_profiles(profile, region, organization_accounts, project_accounts, fetch_mfa_device):
@@ -565,18 +561,17 @@ def configure_accounts_profiles(profile, region, organization_accounts, project_
         profile(str): Name of the profile to configure.
         region (str): Region.
         organization_accounts (dict): Name and id of all accounts in the organization.
-        project_accounts (dict): Name and email of all accounts in project configuration file.
+        project_accounts (list): Name and email of all accounts in project configuration file.
         fetch_mfa_device (bool): Whether to fetch MFA device for profiles.
     """
-    short_name, type = profile.split("-")
+    short_name, _type = profile.split("-")
 
     mfa_serial = ""
     if fetch_mfa_device:
         logger.info("Fetching MFA device serial.")
         mfa_serial = _get_mfa_serial(profile)
         if not mfa_serial:
-            logger.error("No MFA device found for user.")
-            raise Exit(1)
+            raise ExitError(1, "No MFA device found for user.")
 
     account_profiles = {}
     for account in project_accounts:
@@ -593,13 +588,13 @@ def configure_accounts_profiles(profile, region, organization_accounts, project_
         account_profile = {
             "output": "json",
             "region": region,
-            "role_arn": f"arn:aws:iam::{account_id}:role/{PROFILES[type]['role']}",
+            "role_arn": f"arn:aws:iam::{account_id}:role/{PROFILES[_type]['role']}",
             "source_profile": profile,
         }
         if mfa_serial:
             account_profile["mfa_serial"] = mfa_serial
         # A profile identifier looks like `le-security-oaar`
-        account_profiles[f"{short_name}-{account_name}-{PROFILES[type]['profile_role']}"] = account_profile
+        account_profiles[f"{short_name}-{account_name}-{PROFILES[_type]['profile_role']}"] = account_profile
 
     logger.info("Backing up account profiles file.")
     _backup_file("config")