Skip to content

Commit

Permalink
Merge pull request #78 from DSACMS/sandbox-deploy-action
Browse files Browse the repository at this point in the history 
Sandbox deploy action
  • Loading branch information
@YvetteWhiteUSDS
YvetteWhiteUSDS authored Nov 13, 2024
2 parents 2609eab + dd8ab1f commit d73781c
Show file tree
Hide file tree
Showing 2 changed files with 102 additions and 37 deletions.
18 changes: 13 additions & 5 deletions .github/workflows/deploy-to-sandbox.yml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -3,14 +3,18 @@ name: Deploy to Sandbox
on:
workflow_dispatch:
inputs:
service-acct-username:
service_acct_username:
description: 'Cloud.gov service account username'
required: true
type: string
service-acct-password:
service_acct_password:
description: 'Cloud.gov service account password'
required: true
type: string
application_name:
description: 'Application name (uses manifest.yml if blank)'
required: false
type: string

jobs:
deployment:
Expand All @@ -36,9 +40,13 @@ jobs:

- name: Deploy app to sandbox
id: deploy-to-cloudgov-sandbox
# Mask input values so that values do not appear as clear text in the logs.
run: |
SVC_ACCT_PASSWORD=$(jq -r '.inputs.service-acct-password' $GITHUB_EVENT_PATH)
SVC_ACCT_USERNAME=$(jq '.inputs.service_acct_username' $GITHUB_EVENT_PATH)
SVC_ACCT_PASSWORD=$(jq '.inputs.service_acct_password' $GITHUB_EVENT_PATH)
echo "::add-mask::${SVC_ACCT_USERNAME}"
echo "::add-mask::${SVC_ACCT_PASSWORD}"
echo SVC_ACCT_USERNAME=$SVC_ACCT_USERNAME >> $GITHUB_OUTPUT
echo SVC_ACCT_PASSWORD=$SVC_ACCT_PASSWORD >> $GITHUB_OUTPUT
./cf login -a api.fr.cloud.gov -u ${{ github.event.inputs.service-acct-username }} -p $SVC_ACCT_PASSWORD
./cf push
./cf login -a api.fr.cloud.gov -u $SVC_ACCT_USERNAME -p $SVC_ACCT_PASSWORD
./cf push ${{ github.event.inputs.application_name }}
121 changes: 89 additions & 32 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -25,10 +25,10 @@ Accessibility, unit testing, and translation are being built in from the ground
## Repository structure
This application uses NextJS's default file structure. You can learn more about this from [NextJS](https://nextjs.org/docs/getting-started/project-structure).

#### `adr`
### `adr`
Architecture design records are in this directory.

#### `app`
### `app`
Next has a style where routing is determined by file structure. You'll find all of the application files inside of the `app` directory.
* `[locale]`: where the pages live
* `api`: looks like api endpoints with some automagic nextjs things
Expand All @@ -37,15 +37,29 @@ Next has a style where routing is determined by file structure. You'll find all
* `components`: reused components in the application
* `i18n`: translation keys

#### `lib`
### `lib`
`features` contains our redux stores, which is our data structure in this local-storage-focused app. You'll notice below that there's a question about Store default values and other data structure thoughts below in our notes and decisions but for now this is where we're keeping our data structures. As things become more complicated we will want to revisit our decisions in this area.

#### `public`
### `public`
Where any public assets are stored.

#### `scripts`
### `scripts`
Tooling and scripts to make the repository run smoothly and correctly.


## Branching model
This project follows [trunk-based development](https://trunkbaseddevelopment.com/), which means:

* Make small changes in [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/) and merge to `main` frequently.
* Be open to submitting multiple small pull requests for a single ticket (i.e. reference the same ticket across multiple pull requests).
* Treat each change you merge to `main` as immediately deployable to production. Do not merge changes that depend on subsequent changes you plan to make, even if you plan to make those changes shortly.
* Ticket any unfinished or partially finished work.
* Tests should be written for changes introduced, and adhere to the text percentage threshold determined by the project.

This project uses **continuous deployment** using [Github Actions](https://github.com/features/actions) which is configured in the [./github/worfklows](.github/workflows) directory.

Pull-requests are merged to `main`.

## Development

### Starting the application locally
Expand Down Expand Up @@ -112,51 +126,94 @@ As a result, the Dockerfile sets the `PUPPETEER_SKIP_CHROMIUM_DOWNLOAD` environm

## Tests and linting

To run tests:
```bash
# to run tests
npm run test
# to check test coverage
```

To check the test coverage:
```bash
npm run coverage
```

### Coding style and linting
This application uses NextJS's built in linter. It's run as part of pull request checks and you cannot merge without all checks passing.
This application uses the linter in NextJS and is executed as part of the pull request checks and you cannot merge without all checks passing.
To run the linter locally:
```bash
npm run lint
```

To run the linter locally, use `npm run lint`.
## Deploy

## Branching model
This project follows [trunk-based development](https://trunkbaseddevelopment.com/), which means:
This section refers to deploying to a cloud.gov sandbox environment.

* Make small changes in [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/) and merge to `main` frequently.
* Be open to submitting multiple small pull requests for a single ticket (i.e. reference the same ticket across multiple pull requests).
* Treat each change you merge to `main` as immediately deployable to production. Do not merge changes that depend on subsequent changes you plan to make, even if you plan to make those changes shortly.
* Ticket any unfinished or partially finished work.
* Tests should be written for changes introduced, and adhere to the text percentage threshold determined by the project.
### Set up your cloud.gov sandbox environment
The following steps only need to be done once per person. Once you have set up your sandbox environment, you will be able to deploy the application to it and access it publically.

This project uses **continuous deployment** using [Github Actions](https://github.com/features/actions) which is configured in the [./github/worfklows](.github/workflows) directory.
#### Sign up for an account
Before being able to deploy into cloud.gov, you will need to sign up for a sandbox account on the platform. Only federal employees and contractors with a qualified US federal government email may obtain free sandbox space. To register, go to the [sign up page](https://account.fr.cloud.gov/signup). You will need access to your email and an authenticator app (such as Google Authenticator, 1password, Microsoft Authenticator, or Authy).

Pull-requests are merged to `main`.
#### Download the Cloud Foundry CLI

## Deploy
1. Go to https://github.com/DSACMS/iv-verify/actions/workflows/deploy.yml
1. Click "Run Workflow" button on the right
1. Click "Run Workflow" in the dialog that appears
Refer to the [Getting Started - Setting up the command line](https://cloud.gov/docs/getting-started/setup/#set-up-the-command-line) documentation on cloud.gov. The instructions will step through how to set up the Cloud Foundry command line interface and authenticate to your cloud.gov instance.

### Change sandbox locations
#### Establish the application in your sandbox
Here is how to migrate from one deployment namespace to another. We'll need to run a manual deployment to set up the namespace before setting up the gh action to reflect the new location.
1. In the new owner's repo, `npm i && npm run build` if you haven't already
2. Edit the `manifest.yml` to create the name you want. I've been using `verify-ledger-prototype`
2. `cf push [name-in-manifest]`

On successful deployment, you can set up the gh actions deployment
1. `cf create-service cloud-gov-service-account space-deployer [name-in-manifest]`
2. `cf create-service-key [name-in-manifest] [your-key-name]`
3. `cf service-key [name-in-manifest] [your-key-name]`
4. A username and password will be printed in your terminal. Using these, proceed to the next steps:
5. `gh secret set CLOUD_GOV_DEPLOY_USERNAME` and enter this secret when prompted
6. `gh secret set CLOUD_GOV_DEPLOY_PASSWORD` and enter this secret when prompted
7. From here, test out a deployment in the repo to test it out
Reference: https://cloud.gov/docs/services/cloud-gov-service-account/#how-to-create-an-instance

#### Create a service account for your deployments

To create a service account to use for deployments, first create a service instance associated with your
```bash
cf create-service cloud-gov-service-account space-deployer [name-in-manifest]
# For example:
cf create-service cloud-gov-service-account space-deployer verify-ledger-prototype
```

Next, create a service account and bind it to your service instance.
```bash
cf create-service-key [name-in-manifest] [your-key-name]
# For example:
cf create-service-key verify-ledger-prototype ledger-service-key
```

Generate the service key for the account.
```bash
cf service-key [name-in-manifest] [your-key-name]
# For example:
cf service-key verify-ledger-prototype ledger-service-key
```

The command will output a username and password that you will use for deploying the application. You will be prompted for your credentials when using the sandbox deployment workflow.

{
"credentials": {
"password": "oYasdfliaweinasfdliecVfake/",
"username": "fakebeed-aabb-1234-feha0987654321000"
}
}

### Deploy to the cloud.gov sandbox environment
The repository has a workflow for building and deploying the application to a cloud.gov sandbox.

1. Go to https://github.com/DSACMS/iv-verify/actions/workflows/deploy-to-sandbox.yml.
1. Click "Run Workflow" button on the right.
1. Fill out the following three fields:

| Field | Required | Description |
| --- | --- | --- |
| Cloud.gov service account username | Yes | The user name of service account of the sandbox owner's space. |
| Cloud.gov service account password | Yes | The password of service account of the sandbox owner's space. |
| Application name | No | The name of the application as it is defined in the owner's sandbox space. If no value is given, then the value in the manifest.yml is used. |
1. Click the "Run Workflow" button in the dialog to start the processing.
#### Deployment resources
- [Set secrets for gh actions](https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions#creating-secrets-for-an-environment)
Expand Down

0 comments on commit d73781c

Please sign in to comment.