Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/cyberark/bash-lib

Library for bash utility methods and tools
https://github.com/cyberark/bash-lib

bash conjbot-notify utility

Last synced: about 1 month ago
JSON representation

Library for bash utility methods and tools

Awesome Lists containing this project

README

        

# bash-lib

Introductory blog post: https://www.conjur.org/blog/stop-bashing-bash/

```
_______________ _______________
.' .' .|
.' .' .' |
.'_______________.'______________ .' |
| ___ _____ ___ || ___ _____ ___ | |
||_=_|__=__|_=_||||_=_|__=__|_=_|| |
______||_____===_____||||_____===_____|| | __________
.' ||_____===_____||||_____===_____|| .' .'|
.' ||_____===_____||||_____===_____|| .' .' |
.'___________|_______________||_______________|.'__________.' |
|.----------.|.-----___-----.||.-----___-----.|| |_____.----------.
|] |||_____________||||_____________||| .' [ |
|| ||.-----___-----.||.-----___-----.||.' | |
|| |||_____________||||_____________|||==========| |
|| ||.-----___-----.||.-----___-----.|| |_____| |
|] o|||_____________||||_____________||| .' [ 'o|
|| ||.-----___-----.||.-----___-----.||.' | |
|| ||| ||||_____________|||==========| |
|| ||| |||.-----___-----.|| |_____| |
|] ||| |||| ||| .' [ |
||__________|||_____________||||_____________|||.'________|__________|
''----------'''------------------------------'''----------''
(o)LGB (o)
```

The place to store functions that are used in pipelines for multiple repos.

Please add whatever is useful to you, but keep it tidy so its still useful to everyone else :)

## Release Status: Alpha
TL;DR: Ready for use, but needs expansion.

The functions in this repo are tested and ready for use, but certain libs
are pretty much place holders (eg logging). Those need further contributions
before they provide a comprehensive solution.

## License: Apache 2.0
See the [license file](LICENSE)

## Usage

Add bash-lib into your project in the way that best fits your workflow. The only requirement is that you **pin the version of
bash-lib that you use**. This is important so that changes to bash-lib do not have the power to break all projects that use
bash-lib. Your project can then test updates to bash-lib and roll forward periodically.

Options:
* Add a submodule: they are an easy way to integrate bash-lib and automatically use a single SHA until manually updated. Submodules add a pointer from a mount point in your repo to the external repo (bash-lib), and require workflow changes to ensure that pointer is derferenced during clone, checkout and some other opertaions.
* Add a subtree: This repo uses subtrees to pull in test dependencies. Subtrees copy an external repo into a subdirectory of the host repo, no workflow changes are required. Subtrees naturally keep a single version of bash-lib until explicitly updated. Note that subtree merge commits do not rebase well :warning:, so best to keep subtree updates in separate PRs from normal commits.
* Clone bash-lib in your deployment process, bash-lib doesn't have to be within your repo, just needs to be somewhere where your scripts can source [init](init). This is where it's most important that you implement a mechanism to always use the same SHA, as a **clone will track master by default, which is not an allowed use of bash-lib**.

Once you have bash-lib cloned in your project, you source two things:

1. Source `bash-lib/init`. This ensures submodules are initalised and sets the BASH_LIB_DIR env var to the absolute path to the bash-lib dir. This makes it easy to source libraries from other scripts.
2. Source `${BASH_LIB_DIR}/lib-name/lib` for any libraries you are interested in.

You are now ready to use bash-lib functions :)

## Structure
The `/init` script sets up everything required to use the library, most
importantly the `BASH_LIB_DIR` variable which gives the absolute path to the root
of the library and should be used for sourcing the modules.

The repo is organized into libraries, each library is a directory that has a
lib file. Sourcing the lib for a library should expose all the functions
that library offers. The lib file may source or reference other supporting
files within it's directory.

```
.
├── libname
│ ├── lib
│ └── supporting-file
├── init # init script, source this first
├── run-tests # top level test script, executes all tests
├── secrets.yml # secrets required for executing tests
├── test-utils
│ ├── bats # git subtree
│ ├── bats-assert-1 # git subtree
│ ├── bats-support # git subtree
│ ├── lib
│ └── tap2junit
└── tests-for-this-repo
├── filehandling.bats
├── fixtures #
│ └── libname # Dir containing test fixtures for a library
├── tap2junit
├── libname.bats # contains tests for libname/lib
├── python-lint # supporting files for python lint
├── run-bats-tests # script to run bats tests
├── run-gitleaks # script to check for leaked secrets
└── run-python-lint # script to run python lint
```

## Contents



Library
Description
Functions




filehandling
Functions relating to file and path handling



  1. bl_abs_path: Ensure a path is absolute





git
Git helpers



  1. bl_git_available: True if git binary or function is available


  2. bl_in_git_repo: True if current directory is a git working directory


  3. bl_github_owner_repo: returns $owner/$repo extracted from the url of the origin remote


  4. bl_repo_root: Find the root of the current git repo.


  5. bl_all_files_in_repo: List files tracked by git, excludes submodules.


  6. bl_remote_latest_tag: Returns the symbolic name of the latest tag from a remote.


  7. bl_remote_latest_tagged_commit: Returns the SHA of the most recently tagged commit in a remote repo (tag^{}).


  8. bl_remote_sha_for_ref: Returns the SHA for a given ref from a named remote.


  9. bl_remote_tag_for_sha: Returns the tag corresponding to a SHA from a named remote - if there is one.


  10. bl_tracked_files_excluding_subtrees: List files tracked by git, but excluding any files that are in paths listed in .gittrees.


  11. bl_gittrees_present: Succeeds if .gittrees is present in the root of the repo, otherwise fails.


  12. bl_cat_gittrees: Returns the contents of .gittrees from the top level of the repo, excluding any comments. Fails if .gittrees is not present.





github
Github Related Functions



  1. bl_hub_available: True if hub binary or function is available


  2. bl_hub_creds_available: True if hub creds are available (file or env vars)


  3. bl_hub_check: Preflight check for hub, true if git installed, in git repo, hub installed and hub creds are available


  4. bl_hub_download_latest: Download latest hub binary from github and install to ~/bin or specified path


  5. bl_hub_issue_number_for_title: Find the issue number for an issue from its title, searches open issues in the current repo. (current repo = workding directory, repo is found by origin remote). If multiple issues match the supplied title string, only the first is returned.


  6. bl_hub_add_issue_comment: Add a comment to an issue


  7. bl_hub_comment_or_create_issue: Create issue if an issue matching the title doesn't exist. If a match is found, add a comment to it




helpers
Bash scripting helpers



  1. bl_die: print message and exit 1


  2. bl_fail: print message and return 1


  3. bl_spushd/bl_spopd: Safe verisons of pushd & popd that call die if the push/pop fails, they also drop stdout.


  4. bl_is_num: Check if a value is a number via regex


  5. bl_retry: Retry a command until it succeeds up to a user specified maximum number of attempts. Escalating delay between attempts.


  6. bl_retry_constant: Retry a command until it succeeds with a
    constant delay between attempts





k8s
Utils for connecting to K8s



  1. bl_build_gke_image: Build docker image for running kubectl commands against GKE.


  2. bl_delete_gke_image: Delete image from GKE.


  3. bl_run_docker_gke_command: Run command in gke-utils container, already authenticated to k8s cluster.





logging
Helpers related to logging.



  1. bl_announce: Echo message in ascii banner to distinguish it from other log messages.


  2. bl_log: Log a message at the specified level. Default log level is info, change level by setting environment variable BASH_LIB_LOG_LEVEL


  3. bl_check_log_level: Check if a value is a valid bash lib
    log level


  4. bl_debug: Log a message at debug level


  5. bl_info: Log a message at info level


  6. bl_warning: Log a message at warning level


  7. bl_error: Log a message at error level


  8. bl_fatal: Log a message at fatal level





Ruby
Helpers related to ruby infrastructure



  1. bl_gem_latest_version: Return the latest version of a gem from rubygems.org


  2. bl_jq_available: Check jq binary is available


  3. bl_curl_available: Check curl binary is available





test-utils
Helpers for executing tests



  1. bl_shellcheck_script: Execute shellcheck against a script, uses docker.


  2. bl_find_scripts: Find git tracked files with extension.


  3. bl_tap2junit: Convert a subset of TAP to JUnit XML. Retains logs for errors.


  4. bl_validate_changelog: Check CHANGELOG.md (or a specified file) complies with keepachangelog.com format.




# Contributing
For further information on contributing, style & testing, please see [CONTRIBUTING.md](CONTRIBUTING.md)

# Maintainers
* [Hugh Saunders](https://github.com/hughsaunders)