{"id":22313330,"url":"https://github.com/nwops/release_manager","last_synced_at":"2025-07-29T10:32:29.563Z","repository":{"id":48379742,"uuid":"91031591","full_name":"nwops/release_manager","owner":"nwops","description":"Workflow automations around releasing and deploying puppet modules within r10k environments","archived":false,"fork":false,"pushed_at":"2023-01-03T14:38:50.000Z","size":240,"stargazers_count":5,"open_issues_count":5,"forks_count":1,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-04-05T11:11:21.706Z","etag":null,"topics":["gitlab","puppet","r10k","workflow"],"latest_commit_sha":null,"homepage":null,"language":"Ruby","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/nwops.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-05-11T23:24:43.000Z","updated_at":"2022-10-04T16:29:43.000Z","dependencies_parsed_at":"2023-02-01T06:30:32.061Z","dependency_job_id":null,"html_url":"https://github.com/nwops/release_manager","commit_stats":null,"previous_names":[],"tags_count":25,"template":false,"template_full_name":null,"purl":"pkg:github/nwops/release_manager","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Frelease_manager","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Frelease_manager/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Frelease_manager/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Frelease_manager/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/nwops","download_url":"https://codeload.github.com/nwops/release_manager/tar.gz/refs/heads/master","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/nwops%2Frelease_manager/sbom","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":267670314,"owners_count":24125126,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-07-29T02:00:12.549Z","response_time":2574,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["gitlab","puppet","r10k","workflow"],"created_at":"2024-12-03T22:06:58.750Z","updated_at":"2025-07-29T10:32:29.120Z","avatar_url":"https://github.com/nwops.png","language":"Ruby","funding_links":[],"categories":[],"sub_categories":[],"readme":"```shell\n\n__________       .__                                   _____                                             \n\\______   \\ ____ |  |   ____ _____    ______ ____     /     \\ _____    ____ _____     ____   ___________ \n |       _// __ \\|  | _/ __ \\\\__  \\  /  ___// __ \\   /  \\ /  \\\\__  \\  /    \\\\__  \\   / ___\\_/ __ \\_  __ \\\n |    |   \\  ___/|  |_\\  ___/ / __ \\_\\___ \\\\  ___/  /    Y    \\/ __ \\|   |  \\/ __ \\_/ /_/  \u003e  ___/|  | \\/\n |____|_  /\\___  \u003e____/\\___  \u003e____  /____  \u003e\\___  \u003e \\____|__  (____  /___|  (____  /\\___  / \\___  \u003e__|   \n        \\/     \\/          \\/     \\/     \\/     \\/          \\/     \\/     \\/     \\//_____/      \\/       \n```\n\n\u003c!-- START doctoc generated TOC please keep comment here to allow auto update --\u003e\n\u003c!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE --\u003e\n**Table of Contents**  *generated with [DocToc](https://github.com/thlorenz/doctoc)*\n\n- [ReleaseManager](#releasemanager)\n  - [Prerequisites](#prerequisites)\n  - [Installation](#installation)\n    - [Install directly from source](#install-directly-from-source)\n  - [Usage Summary](#usage-summary)\n  - [The workflow problem](#the-workflow-problem)\n    - [R10k Sandbox Creation Steps (the hard way)](#r10k-sandbox-creation-steps-the-hard-way)\n    - [R10k Sandbox Creation steps (the easy way)](#r10k-sandbox-creation-steps-the-easy-way)\n  - [Detailed Usage](#detailed-usage)\n    - [sandbox-create](#sandbox-create)\n    - [release-mod](#release-mod)\n    - [deploy-mod](#deploy-mod)\n    - [bump-changelog](#bump-changelog)\n  - [Common Workflows](#common-workflows)\n    - [Creating releases](#creating-releases)\n    - [Creating one off releases](#creating-one-off-releases)\n  - [Configuration Settings](#configuration-settings)\n    - [Sandbox-create environment variables](#sandbox-create-environment-variables)\n  - [Ssh agent usage](#ssh-agent-usage)\n  - [Development](#development)\n  - [Develpment Environment Setup](#develpment-environment-setup)\n    - [Setting up your Gitlab Instance](#setting-up-your-gitlab-instance)\n    - [Configure your release manager client](#configure-your-release-manager-client)\n    - [Testing the cli commands](#testing-the-cli-commands)\n    - [Debugging](#debugging)\n  - [Contributing](#contributing)\n  - [License](#license)\n\n\u003c!-- END doctoc generated TOC please keep comment here to allow auto update --\u003e\n\n# ReleaseManager\n\nThis gem provides workflow automations around releasing and deploying puppet modules within r10k environments.\n\n## Prerequisites \n\n1. Must be running Gitlab 9.0+\n2. Must be using ssh keys with gitlab\n3. Must be using ssh-agent to handle git authentication\n4. Must be using Git\n5. Must be using r10k\n6. Must have a r10k-control repo (name can vary)\n7. Must have a Gitlab API Access token (per user)\n8. Must have the libssh-dev library package installed\n9. Must tag code with version tags ie. `v1.2.3`\n10. Must keep a CHANGELOG.md\n\n## Installation\n\nAdd this line to your application's Gemfile:\n\n```ruby\ngem 'release_manager'\n```\n\nAnd then execute:\n\n    $ bundle\n\nOr install it yourself as:\n\n    $ gem install release_manager\n    \n\nRelease Manager depends on the Rugged gem which requires compilation and a few OS dependencies.\n\n### Ubnutu / Debian\napt-get update \u0026\u0026 apt-get install libgit2-21 cmake libssh-dev\n\n### RedHat Based\nyum install cmake libssh2 libssh2-devel git\n    \n### Install directly from source\nIf you don't have access to a gem server you can use the `specific_install` gem.  This will install the latest version\ndirectly from source.\n\n```\ngem install specific_install  # unless already installed\ngem specific_install https://github.com/nwops/release_manager  \n```\n\n## Usage Summary\nThere are several cli utilities bundled with the gem, each one can be used independently of the other.  Detailed usage can be\nfound further below in this document.\n\n* `sandbox-create -n my_sandbox`  - Sandbox creation and module repo forking (most popular)\n* `deploy-mod`  - (module) Deploy the latest version of your mod to r10k-control Puppetfile\n* `deploy-mod`  - (r10k repo) Deploy the latest version (tags) of your r10k-control repo branch to other branches\n* `deploy-r10k` - Deploying your r10k repo to other branches in the same repo using merge requests\n* `release-mod`  - Increments version, tags, updates changelog and releases version to gitlab\n* `bump-changelog` - for directly manipulating the changelog\n\n## Automating the release process\nOver the last few years I have adapted the build-\u003erelease-\u003edeploy process to r10k environments. This is done by\ntreating all puppet modules as separate projects, and r10k-control as the AIO (all in one) project the encomposes all the modules.\n\nWhere as most people would only merge the changes from one branch to the production branch, Release Manager expects there are multiple stages to pass in order to get to production.  This greatly reduces risk and follows a similar process to traditional software development.\n\nRelease Manager enforces this process and will version the r10k-control repo just like a module.  Once that version is released, the version is then deployed to the other puppet environments by merging only the differences between the two branches.  This is done purposely as we will be assured that the contents of v0.1.1 have been deployed to the dest branch (qa, staging, and production).  Additionally, you can have multiple versions in flight at any given time.  So a typical scenario can be something like:\n\n - feature_branch ( dev + feature/bugfix)\n - dev (bleeding edge)\n - qa (v1.1.5)\n - staging (v1.1.4)\n - production (v1.0.0)\n \nBecause most people are accustomed to this release process, it becomes easy to trace where changes are at any given moment. Keeping a changelog in r10k-control helps immensely as well.\n\nFuthermore, if you realize a problem with v1.1.4 and need a hotfix, just create a branch `git checkout -b hotfix upstream/v1.1.4` apply the fix, and release a new version.  They deploy the hotfix to any branch you desire.\n\nKeep in mind releases are immutable.  So once you create a release, you have to cut another release to deploy any changes.  This is by design so that you always know what is deployed.\n \n## The workflow problem\nR10k allows us to create a puppet environment for each branch on the r10k-control repository. This makes isolating code deployments\nsimple to use because each branch corresponds to a puppet environment.  However, this workflow implies that you will fork\nall the modules you work on and create branches on those forks.  Additionally, you then need to update the r10k-control Puppetfile\nto use those new branches and forks.  This can be a huge burden and consume some of your time.  Below is an example of that workflow.\n\n### R10k Sandbox Creation Steps (the hard way)\n1. fork r10k-control\n2. clone r10k-control fork\n3. create new branch called my_sandbox on r10k-control fork\n4. Decide which module(s) you need to work on  (ie. roles, profiles, sqlserver) for a given sandbox (branch)\n5. Fork the roles repo\n6. Fork the profiles repo\n7. Fork the sqlserver repo\n8. Clone all three of the forked repos above\n9. Create a branch called my_sandbox on each of the repos above\n10. Update the puppetfile in r10k-control to use your fork and branch for each module above\n11. Commit the puppetfile\n12. Push the commit to the r10k-control\n13. Add the upstream remote for all of the repos you just cloned\n14. Add members to your forked projects\n15. push new branch on each forked project\n\nYikes!  This is a long list of things to do.  It is human nature to skip some or all of these steps to save time even though\nit is in our best interest to follow these steps.  Most humans we will always resort to the path of least resistance. \n\nIn an effort to force good practices and reduce time and effort, release-manager will automate almost all of the tasks into \na single command called `sandbox-create`.\n\nAdditionally there are other commands that help with the release and deploy process of modules to the r10k-control repository.\n\n### R10k Sandbox Creation steps (the easy way)\n`sandbox-create -n my_sandbox --modules='roles,profiles,hieradata,sqlserver'`  \n\n## Detailed Usage\n\nRelease manager provides the following commands to help you create sandboxes, release and deploy puppet code.\n\n### sandbox-create\nThe sandbox-create command wraps all the git, git cloning, and git forking tasks into a single command.  Usage of this command\nwill save you a great deal of time upon each run.\n\nPlease note: this requires the usage of [ssh-agent](#ssh-agent-usage). \n\n\n```\nUsage: sandbox-create [options]\n\nSummary: Creates a new r10k sandbox by forking and creating a new branch on r10k-control,\n         creates a fork and branch for each module passed in, adds the upstream remote\n         for each module, updates the r10k-control Puppetfile to use those forks and branches\n         and pushes the branch to the upstream r10k-control.\n\n\nNote: If you already have any of these modules cloned, this script will attempt to update those modules\n      using git fetch and git checkout -b sandbox_name upstream/master.  So this should not destroy anything.\n\nConfiguration:\n\nThis script uses the following environment variables to automatically set some options, please ensure \nthey exist in your shell environment.  You can set an environment variable in the shell or define \nin your shell startup files.\n\nShell:  export VARIABLE_NAME=value\n\nR10K_REPO_URL            - The git repo url to r10k-control (ie. git@gitlab.com:devops/r10k-control.git)\nGITLAB_API_ENDPOINT      - The api path to the gitlab server  (ie. https://gitlab_server/api/v3)\n                           replace gitlab_server with your server hostname\nGITLAB_API_PRIVATE_TOKEN - The gitlab user api token.  \n                           You can get a token here (http://web/profile/personal_access_tokens, \n                           Ensure api box is checked.\nDEFAULT_MODULES          - The default set of modules to fork use when \n                           a sandbox (ie. export DEFAULT_MODULES='hieradata, roles')\n\nDEFAULT_MEMBERS          - The default members each forked project should add permissions\n                           to ( ie, DEFAULT_MEMBERS='ci_runner,r10k_user' )\n\nIf your gitlab server has a invalid certificate you can set the following variable to \"fix\" that trust issue.\nexport GITLAB_API_HTTPARTY_OPTIONS=\"{verify: false}\"\n\nExamples:\n  sandbox-create -n my_sandbox -m \"roles,profiles,developer\" \n  sandbox-create -n my_sandbox -m \"roles,profiles,developer\" --members=\"p1dksk2,devops,ci_runner\"\n  sandbox-create -n my_sandbox -s \"upstream/v0.5.0\" \n\nOptions:\n        --members DEFAULT_MEMBERS    A comman seperated list of members to add to forked projects\n    -n, --name NAME                  The name of your sandbox\n    -s, --src-target REMOTE/REF      The source of the target to create your sandbox from, defaults to upstream/dev\n        --control-url R10K_REPO_URL  git url to the r10k-control repo, defaults to R10K_CONTROL_URL env variable\n    -m, --modules MODULES            A comma separated list of modules names from the Puppetfile to fork and branch\n    -r, --repos-dir [REPOS_PATH]     The repos path to clone modules to. Defaults to: /home/appuser/repos\n    -c, --control-dir [CONTROL_DIR]  The r10k-control repo path. Defaults to: /home/appuser/repos/r10k-control\n        --verbose                    Extra logging\n\n```\n\nExample Run\n\n```shell\nappuser@28523330e507:/app$ export DEFAULT_MODULES=gitlab \nappuser@28523330e507:/app$ export DEFAULT_MEMBERS=r10k_user,ci_runner\nappuser@28523330e507:/app$ sandbox-create -n sdafsd -m r10k\n\nINFO - ReleaseManager: Resetting upstream remote to git@web:cosman/control-repo.git for /home/appuser/repos/r10k-control\nINFO - ReleaseManager: Fetching upstream from git@web:cosman/control-repo.git\nINFO - ReleaseManager: Resetting upstream remote to git@web:devops/control-repo.git for /home/appuser/repos/r10k-control\nINFO - ReleaseManager: Fetching upstream from git@web:devops/control-repo.git\nINFO - ReleaseManager: Checking out branch: upstream/dev for /home/appuser/repos/r10k-control\nINFO - ReleaseManager: Fetching upstream from git@web:cosman/r10k.git\nINFO - ReleaseManager: Fetching upstream from git@web:cosman/r10k.git\nINFO - ReleaseManager: Updating r10k-control Puppetfile to use fork: git@web:cosman/r10k.git with branch: sdafsd\nINFO - ReleaseManager: Adding member r10k_user to project cosman/puppet-gitlab\nINFO - ReleaseManager: Adding member ci_runner to project cosman/puppet-gitlab\nINFO - ReleaseManager: Resetting upstream remote to git@web:cosman/puppet-gitlab.git for /home/appuser/repos/gitlab\nINFO - ReleaseManager: Fetching upstream from git@web:cosman/puppet-gitlab.git\nINFO - ReleaseManager: Fetching upstream from git@web:cosman/puppet-gitlab.git\nINFO - ReleaseManager: Updating r10k-control Puppetfile to use fork: git@web:cosman/puppet-gitlab.git with branch: sdafsd\nINFO - ReleaseManager: Checking out branch: sdafsd for /home/appuser/repos/r10k-control\nINFO - ReleaseManager: Committing Puppetfile changes to r10k-control branch: sdafsd\n\n```\n\n**Note: This script assumes you will have the following environment variables set:**\n\nYou can throw this in your .bash_profile or .zprofile and have this set automatically for each run.\n\nExample Only:\n\n```\nexport GITLAB_API_ENDPOINT='http://web/api/v3'\nexport GITLAB_API_PRIVATE_TOKEN='A_zJJfgE8P-8mFGK2_r9'\nexport R10K_REPO_URL=\"git@web:devops/control-repo.git\"\n\n```\n\n### release-mod\nThe `release-mod` command will help you release new module and r10k-control repo code by doing the following\n1. increment the version in the metadata.json file version field\n2. increment the version in the changelog file\n3. create a commit with the above changes\n4. create a git tag with the name as the version ie. v0.1.4\n5. push the changes and tag to the upstream repo using the metadata.json's source field\n\n```\nUsage: release-mod [options]\n\nSummary: Bumps the module version to the next revision and\n         updates the changelog.md file with the new\n         version by reading the metadata.json file. This should\n         be run inside a module directory.\n\n    -d, --dry-run                    Do a dry run, without making changes\n    -a, --auto                       Run this script without interaction\n    -l, --level\t\t\t     Semantic versioning level to bump (major.minor.patch), defaults to patch\n    -m, --module-path                The path to the module, defaults to current working directory\n    -b, --no-bump                    Do not bump the version in metadata.json\n    -r, --repo [REPO]                The repo to use, defaults to repo found in the metadata source\n        --verbose                    Extra logging\n```\n\n### deploy-mod\nThe `deploy-mod` command assists you with updating an r10k environment with the new module version by doing the following.\n1. search the r10k-control repo's Puppetfile for a module with a similar name of the current module\n2. removes the branch or ref argument from the \"mod\" declaration\n3. adds a tag argument with the latest version defined in the module's metadata.json file.\n\nYou can also optionally pass in the `--commmit` flag to create a commit.  \n\nAdditonally if you wish to push the current branch you can also\npass in the `--push` and `--remote r10k-control` option.\n\n```\nUsage: deploy-mod [options]\n\nSummary: Gets the version of your module found in the metadata\n         and populates the r10k-control Puppetfile with the updated\n         tag version. Revmoes any branch or ref reference and replaces\n         with tag.  Currently it is up to you to commit and push the Puppetfile change.\n\n    -p, --puppetfile PUPPETFILE      Path to R10k Puppetfile, defaults to ~/repos/r10k-control/Puppetfile\n    -m, --modulepath MODULEPATH      Path to to module, defaults to: /home/p1cxom2/repos/release_manager\n    -c, --commit                     Commit the Puppetfile change\n    -u, --push                       Push the changes to the remote\n    -r, --remote REMOTE              Remote name or url to push changes to\n```\n\n### bump-changelog\nThe `bump-changelog` command simply changes 'Unreleased' section with the version string found the in the module's metadata file\nand creates a new 'Unrelease Section on top\n1. increment version in changelog\n2. create commit with change\n\nIf using the `release-mod` command there is no need to run the `bump-changelog`command as it is part of the process already.\n\n## Common Workflows\n### Creating releases\nYou worked hard on your code and now you want to release your software for others to enjoy.\nFollow the steps below to version your code before deployment.  This these changes are considered major\nwe want to create a 2.0.0 release.\n\n1. run `release-mod -l major` from the root of the module directory (use `-d` for a dry run)\n\nThat's it, all you need to do is run that command.  Note, by design you are not allowed to enter a version number.  Release Manager\nuses the version in metadata.json file as a reference and increments to semver identifiers. \n\n\n### Creating one off releases\n\n1. Did you deploy a release all the way to production only to find a bug?\n2. Do you want to skip all other deployment stages with your patch?\n\nFollow the steps below to create a new patch release and deploy straight to production\n\n1. Create a new sandbox based on the branch or tag you want to fix. `sandbox-create -s upstream/v0.5.0 -n patch_0.5.1`\n2. cd ~/repos/r10k-control\n3. Make your changes in that branch and update the changelog\n4. Push your code to the remote Git repo and activate your CI pipeline (recommended)\n5. Release the new version `release-mod -l patch -s patch_0.5.1`  (creates tag v0.5.1 from the sandbox)\n6. Deploy the patch release to production `deploy-r10k -s v0.5.1 -d production`\n\n## Configuration Settings\nThe following environment variables will automatically set required parameters and defaults.  It is suggested you put \nthis in your shell script like .bash_profile or .zprofile\n\n### Sandbox-create environment variables\n\nGITLAB_API_ENDPOINT - The api path to the gitlab server (ie. https://gitlab.com/api/v3)\n\nGITLAB_API_PRIVATE_TOKEN - The gitlab user api token \n\nDEFAULT_MODULES - The default set of modules to use when creating a sandbox  (ie. hieradata)\n\nR10K_REPO_URL - The git repo url to r10k-control (ie. git@gitlab.com:nwops/r10k-control.git)\n\nDEFAULT_MEMBERS - The default members each forked project should add permissions to (ie, 'ci_runner', 'r10k_user')\n\n## Ssh agent usage\nIn order to use sandbox-create you need to ensure you have ssh-agent running in the background and the following \nenvironment variables are exported.  In some cases you might have this automated via a shell login script.\n\n* SSH_AUTH_SOCK\n* SSH_AGENT_PID\n\nAutomated usage\n\n```\n#!/usr/bin/env bash\n#\n# setup ssh-agent\n#\n# set environment variables if user's agent already exists\n[ -z \"$SSH_AUTH_SOCK\" ] \u0026\u0026 SSH_AUTH_SOCK=$(ls -l /tmp/ssh-*/agent.* 2\u003e /dev/null | grep $(whoami) | awk '{print $9}')\n[ -z \"$SSH_AGENT_PID\" -a -z `echo $SSH_AUTH_SOCK | cut -d. -f2` ] \u0026\u0026 SSH_AGENT_PID=$((`echo $SSH_AUTH_SOCK | cut -d. -f2` + 1))\n[ -n \"$SSH_AUTH_SOCK\" ] \u0026\u0026 export SSH_AUTH_SOCK\n[ -n \"$SSH_AGENT_PID\" ] \u0026\u0026 export SSH_AGENT_PID\n\n# start agent if necessary\nif [ -z $SSH_AGENT_PID ] \u0026\u0026 [ -z $SSH_TTY ]; then  # if no agent \u0026 not in ssh\n  eval `ssh-agent -s` \u003e /dev/null\nfi\n\n# setup addition of keys when needed\nif [ -z \"$SSH_TTY\" ] ; then                     # if not using ssh\n  ssh-add -l \u003e /dev/null                        # check for keys\n  if [ $? -ne 0 ] ; then\n    alias ssh='ssh-add -l \u003e /dev/null || ssh-add \u0026\u0026 unalias ssh ; ssh'\n    if [ -f \"/usr/lib/ssh/x11-ssh-askpass\" ] ; then\n      SSH_ASKPASS=\"/usr/lib/ssh/x11-ssh-askpass\" ; export SSH_ASKPASS\n    fi\n  fi\nfi\n\n```\nManual Usage\n\n```\nssh-agent bash\nssh-add\n# this should prompt for password if your ssh key is protected\n\n```\n\n### Unable to exchange encryption keys\nIf you see an error message related to `Unable to exchange encryption keys` you may be dealing with an issue on your git server openssh\ndoes not support the key exchange that libssh2 supports.  Libssh2 is used by release_manager so it is important they can negotiate on the same algorithm.\n\nThere are two possible fixes for this.  \n\n* Update libssh2 to 1.7.x+\n\nYou can grab the libssh2 library on your puppetserver with r10k should you not have access to libssh2-1.7.0+\n\n`cp /opt/puppetlabs/server/apps/r10k/lib/libssh2.so.1.0.1 /usr/lib64/libssh2.so.1.0.1`\n\nNote: you will actually want to copy the the library whereever release_manager is used.  Additionally you need to recompile\nthe rugged gem,  only after updating libssh2 in /usr/lib64\n\n`gem uninstall rugged \u0026\u0026 gem install rugged  `\n\n\nIf you don't want to update libssh2 you should add support more more algorithms on the git server.  \n\n\n```\n# /etc/ssh/sshd_config\n\nKexAlgorithms hmac-sha2-512\n```\n\nNote:  you should have more algorithms as that is an example only.\n\n## Development\n\nAfter checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.\n\nTo install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).\n\n\n## Develpment Environment Setup\n### Setting up your Gitlab Instance\n1. Ensure you have docker and docker-compose installed\n2. run `docker-compose up` to start all the services\n3. Visit http://localhost:8000/\n4. Create a password  (password123)\n5. Login (root/password123)\n6. Create a user account for yourself (add Admin role)\n7. Logout as Admin and login as the new user account\n10. Create a `.env` file in the repo directory and paste these contents in it\n  ```ruby\nGITLAB_API_ENDPOINT='http://web/api/v4'\nGITLAB_API_PRIVATE_TOKEN='your token goes here'\nR10K_REPO_URL=\"git@web:devops/control-repo.git\"\n\n  ```\n11. Create an Personal Access Token (API) token for your user account\n12. Replace the token in your .env file\n\n### Configure your release manager client\n1. run `docker-compose run client`\n2. From the container run source .env\n3. From client container `source .bash_profile`\n4. Add the ~/.ssh/id_rsa.pub key to your gitlab account\n5. From the new client container session, run `bundle exec bash app_startup_script.sh`\n6. From the client container, run `bundle exec ruby setup_repos.rb`\n7. From the client container attempt to connect to the git server and accept the key `ssh git@web`\n8. Test to ensure you can clone a repository inside the container `git clone git@web:devops/docker.git /tmp/docker`\n\n### Testing the cli commands\n1. `bundle exec exe/sandbox-create -n my_sandbox -m docker`  # example\n2. `bundle exec exe/release-mod --level minor -m ~/repos/docker`\n\n### Debugging\nif you cannot connect to the gitlab server via ssh you see errros about private key \nhas wrong permission you will need to do the following:\n\n`chmod 600 srv/gitlab/config/ssh_host_ecdsa_key srv/gitlab/config/ssh_host_ed25519_key srv/gitlab/config/ssh_host_rsa_key`\n\nIf the sandbox create command freezes after the first output make sure you can connect\nto the git server using git clone or running `ssh-add` to add your ssh key to the ssh agent.\n\n## Contributing\n\nBug reports and pull requests are welcome on release_manager.\n\n\n## License\n\nThe gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).\n\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnwops%2Frelease_manager","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fnwops%2Frelease_manager","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fnwops%2Frelease_manager/lists"}