manage.get.gov/.github/ISSUE_TEMPLATE/developer-onboarding.md

name	about	title	labels	assignees
Developer Onboarding	Onboarding steps for developers.	Developer Onboarding: GH_HANDLE	dev, onboarding	abroddrick

Developer Onboarding

• Onboardee: GH handle of person being onboarded
• Onboarder: GH handle of onboard buddy

Installation

There are several tools we use locally that you will need to have.

• Install the cf CLI v7 for the ability to deploy
• Make sure you have gpg >2.1.7. Run gpg --version to check. If not, install gnupg
• Install the Github CLI

Access

Steps for the onboardee

• Setup commit signing in Github and with git locally.
• Create a cloud.gov account
• Email github@cisa.dhs.gov (cc: Cameron) to add you to the CISA Github organization and .gov Team.
• Ensure you can login to your cloud.gov account via the CLI

cf login -a api.fr.cloud.gov  --sso

• Have an admin add you to cloud.gov org and set up your sandbox developer space. Ensure you can deploy to your sandbox space.
• Have an admin add you to our login.gov sandbox team (.gov Registrar) via the dashboard.

Note: As mentioned in the Login documentation, the sandbox Login account is different account from your regular, production Login account. If you have not created a Login account for the sandbox before, you will need to create a new account first.

• Optional- add yourself as a codeowner if desired. See the Developer readme for how to do this and what it does.

Steps for the onboarder

• Add the onboardee to cloud.gov org (cisa-dotgov)
• Setup a developer specific space for the new developer
• Add the onboardee to our login.gov sandbox team (.gov Registrar) via the dashboard

Documents to Review

• Team Onboarding
• Architecture Decision Records
• Contributing Policy

Setting up commit signing

Follow the instructions here to generate a new GPG key (default configurations are okay) and add it to your GPG keys on Github.

Configure your key locally:

git config --global commit.gpgsign true
git config --global user.signingkey <YOUR KEY>

Where your key is the thing you generated to run the command

gpg --armor --export <YOUR KEY>

when setting up your key in Github.

Now test commit signing is working by checking out a branch (yourname/test-commit-signing) and making some small change to a file. Commit the change (it should prompt you for your GPG credential) and push it to Github. Look on Github at your branch and ensure the commit is verified.

Note: if you are on a mac and not able to successfully create a signed commit, getting the following error:

error: gpg failed to sign the data
fatal: failed to write commit object

You may need to add these two lines to your shell's rc file (e.g. .bashrc or .zshrc)

GPG_TTY=$(tty)
export GPG_TTY

and then

source ~/.bashrc

or

source ~/.zshrc

Setting up developer sandbox

We have three types of environments: stable, staging, and sandbox. Stable (production)and staging (pre-prod) get deployed via tagged release, and developer sandboxes are given to get.gov developers to mess around in a production-like environment without disrupting stable or staging. Each sandbox is namespaced and will automatically be deployed too when the appropriate branch syntax is used for that space in an open pull request. There are several things you need to setup to make the sandbox work for a developer.

All automation for setting up a developer sandbox is documented in the scripts for creating a developer sandbox and removing a developer sandbox. A Cloud.gov organization administrator will have to perform the script in order to create the sandbox.