1. Tell the rest of the team (via your Slack channel) that you are setting up the Kanban board.

2. Go to your team03 repo. At this stage, it doesn’t matter whether it’s still empty, or whether it already has stuff in it.

   Section	1	2	3	4
   4pm	team03-s22-4pm-1	team03-s22-4pm-2	team03-s22-4pm-3	team03-s22-4pm-4
   5pm	team03-s22-5pm-1	team03-s22-5pm-2	team03-s22-5pm-3	team03-s22-5pm-4
   6pm	team03-s22-6pm-1	team03-s22-6pm-2	team03-s22-6pm-3	team03-s22-6pm-4

3. Click on the Projects tab. It should look like this:

   

4. Click on the bottom Projects button (not the Beta one, but the other one). Your screen should then look like this:

   

5. Click the green New Project button, at upper right. Your screen should then look like this:

   

6. Fill in the project name with your team name (e.g. s22-4pm-1). You can leave the description blank. Then select Automated Kanban with Reviews from the dropdown menu (as shown), and finally click the Create Project button.

7. In the To Do column, you’ll now have some annoying starter cards, as shown below. Click in the three dots at upper right on each of them to get rid of them, so that you have an empty board:

   

   When done, it should look like this:

   

8. Congratulations: your team can now start adding issues to your Kanban board.

One team member should clone the team03 repo, which should be found here:

Steps (illustrated below)

That should establish the main branch of your repo so that everyone on the team can then clone it and use it as a starting point.

In this task, you’ll set up a GitHub Pages site for documentation of your code base; for now, that just consists of the published Storybook, which is an interactive catalog of all of your React components.

To do this, follow these steps:

1. Create a new repo under the course organization ucsb-cs156-s22 that has the same name as your team03 repo (e.g. team03-s22-4pm-1) but with -docs appended to the end of the name (for example, team03-s22-4pm-1-docs.)
2. Now do the same step again, creating a repo with -docs-qa (for example, team03-s22-4pm-1-docs.)
3. In each of these repos, create a file called /docs/README.md. This is necessary to establish the main branch, and the /docs folder. The contents are not important for now, since they will be overridden later.

4. In each of these repos, go to the Settings page for the repo, then look for Pages in the left navigation. You want to enable GitHub pages, so that the settings look like this:

   

5. Go to the settings page for your personal GitHub account, like this:

   

6. Find the Developer Settings in the left navigation, near the bottom.

   

7. On the developer settings, choose Personal Access Token

8. Click Generate New Token. You’ll need to confirm your password.

9. Fill in the description with your team03 repo name (like shown below). Note that the description is just for humans, so the formatting doesn’t have to be exact. This is just so you can remember what the token is for.

   Select 90 days for the expiration, and then select repo as the only scope (it includes all the detailed scopes underneath).

   

   Finally, scroll down and click Generate Token.

   

   You’ll be shown a token value (this one is fake and has been deactivated). Copy it, because once you close the window it’s gone, but DO NOT PASTE IT ANYWHERE except in the secrets portion of your team03 repo (next step). This value can be used in place of your GitHub password, so you need to protect it.

   

10. Return to your main team03 repo, and go to Settings page for Secrets: Actions (This is done on the regular team03-s22-4pm-1 repo, NOT on the -docs and -docs-qa repos.)

    

    On the Secrets page click New Repository Secret then add a secret called DOCS_TOKEN. Be careful here, because the name must be exactly DOCS_TOKEN, not DOC_TOKEN or anything else; this value is referenced in the GitHub workflow scripts.

    

    After you are done, it should look like this:

    

    If you need to replace the secret (e.g. for debugging reason), you can overwrite it, but once you store it, you can’t look at it. So if you get it wrong, you just have to create a new one; you can’t edit the old value.

11. Now, once DOCS_TOKEN is updated, and till in your main team03 repo, and go to the page for GitHub Actions (the Actions tab). You should see these workflows in the list on the left:

    

    Click on the job that starts with 02-publish-docs-to-GitHub and you should see this:

    

    On the right hand side of the screen, find where it says Run Workflow, and click it. That should expose this box:

    

    Click Run Worfklow

12. Repeat this step for the job that starts with 04-publish-docs-to-GitHub.

13. When each of these two jobs is finished, you should be able to navigate to your GitHub Pages sites at URLs like this (subsitute your own team name):

    • https://ucsb-cs156-s22.github.io/team03-s22-5pm-3-docs
    • https://ucsb-cs156-s22.github.io/team03-s22-5pm-3-docs-qa

    And these links should show a Storybook page like the ones shown below (except your team name will show instead of STARTER-team03. The branches listed may be different two, but this is the general idea of what the pages should look like.

    

    

14. Go into the README.md file of your main team03 repo, and edit the links to the documentation. They will look like this when you start:

    TODO: Add correct links to the -docs and -docs qa GitHub pages sites
    
    * Storybook (production): <https://ucsb-cs156-s22.github.io/STARTER-team03-docs>
    * Storybook (development/qa): <https://ucsb-cs156-s22.github.io/STARTER-team03-docs-qa>
    

    After you edit, it should look like this (with links appropriate for your team). Note that you should remove the part that says TODO.

    * Storybook (production): <https://ucsb-cs156-s22.github.io/team03-s22-6pm-4-docs>
    * Storybook (development/qa): <https://ucsb-cs156-s22.github.io/team03-s22-6pm-4-docs-qa>
    

That’s it for this task.

NEW: Giving your team access

Just Kidding! Here’s one more step.

Do this step for both the team03-s22-6pm-4-docs and team03-s22-6pm-4-docs-qa repos for your team:

1. Visit the Settings page for the repo
2. Visit the Collaborators and Teams link (second on left navivation)

3. You should see your own GitHub (the one of the person that created the repo) in the list of folks with access. You should click the Add Team button (upper right) to add your entire team:

   

   You’ll see this pop-up modal:

   

4. Type in your team name (e.g. s22-5pm-2) and the team name shoudl pop up so that you can add it.

   

5. Click the button, and the modal should change to look like this:

   

6. Change the permission level to Admin, and the click to add your team.

   

7. It should add your team to the list of folks with access:

   

Ok .. NOW you are done.

In this task, you’ll make sure that Codecov is set up to track the main branch instead of master, and you’ll add the correct Codecov badge to your repo’s README.md file.

Task 2 needs to be done first, so that the main repo has code in it, and the CI/CD jobs for the first push of code have finished running.

1. Visit the link https://app.codecov.io/gh/ucsb-cs156-s22/team03-s22-5pm-3 (where s22-5pm-3 is replaced with your team name)

2. Navigate to Settings. It should look like this. (Note that the token shown has been regenerated; it’s no longer valid.)

   

3. If the Default Branch shows master, change it to main and click Update.

4. Click where it says Badge at left, and you should see something like this:

   

   Click the button to copy the markdown for the Badge.

5. Go to your team03 README.and edit it to find where the Codecov badge needs to be replaced. It should look like this:

   TODO: Add a codecov badge for the main branch here.  What's shown is an example, but you need to visit codecov to get the markdown for your repo; don't just try to edit the markdown in the example below.  The token value won't match your repo.  Be sure to adjust the default branch from `master` to `main`.
   
   [![codecov](https://codecov.io/gh/ucsb-cs156-s22/STARTER-team03/branch/main/graph/badge.svg?token=s3OvSANaki)](https://codecov.io/gh/ucsb-cs156-s22/STARTER-team03)
   

   Replace that by pasting in the correct markdown for the badge, and removing the TODO text:

That’s it for this task.

To save time, we are going to reuse the Heroku prod instance from team02 for team03.

A link to the dashbaord of your team02 Heroku Prod insttance appears below. Check that it’s still active.

Make sure that the application is still up, and that you can use Google OAuth to login.

If so, then to save time: do not change the name of the app. If you do, then OAuth will break, since it depends on exactly the name you already have.

Since team03 builds on team02, it’s fine for us to use the same deployment.

Note: At the time of this exercise, 05/12/2022, the Heroku/GitHub interface in the web dashboard is disabled, due to a security breach at Heroku. If/when it’s restored, the following instructions could be simplified. For now, we have to do this at the command line.

Next, you’ll want to clone the repo on your local system.

Change directory (cd) into the repo, and then issue this command, substituting in your Heroku app name:

heroku git:remote -a s22-4pm-2-team02

Then, do this command to push the main branch to the Heroku deployment:

git push heroku main

This should deploy the starter code to the Heroku app.

If it works, you have just one more step: Edit the README.md of your main repo to fix the link to the production deployment.

It will start out looking like this:

TODO: Add a link to the deployed Heroku app for your team here, e.g.

* <https://s22-7pm-3-team02.herokuapp.com>  

Change it so it looks like this (removing the TODO, and replacing s22-7pm-3 with your team name:

* Production deployment: <https://s22-7pm-3-team02.herokuapp.com>  

That’s it for this task.

This is the same as Setup Task 5, except for the qa deployment instead of prod.

To save time, we are going to reuse the Heroku prod instance from team02 for team03.

A link to the dashbaord of your team02 Heroku qa insttance appears below. Check that it’s still active.

Make sure that the application is still up, and that you can use Google OAuth to login.

If so, then to save time: do not change the name of the app. If you do, then OAuth will break, since it depends on exactly the name you already have.

Since team03 builds on team02, it’s fine for us to use the same deployment.

Note: At the time of this exercise, 05/12/2022, the Heroku/GitHub interface in the web dashboard is disabled, due to a security breach at Heroku. If/when it’s restored, the following instructions could be simplified. For now, we have to do this at the command line.

Next, you’ll want to clone the repo on your local system.

Change directory (cd) into the repo, and then issue this command, substituting in your Heroku app name:

heroku git:remote -a s22-4pm-2-team02-qa --remote heroku-qa

Then, do this command to push the main branch to the Heroku deployment:

git push heroku-qa main

This should deploy the starter code to the Heroku app.

If it works, you have just one more step: Edit the README.md of your main repo to fix the link to the production deployment.

It will start out looking like this:

TODO: Add a link to the deployed Heroku qa app for your team here, e.g.

* <https://s22-7pm-3-team02-qa.herokuapp.com>  

Change it so it looks like this (removing the TODO, and replacing s22-7pm-3 with your team name:

* QA deployment: <https://s22-7pm-3-team02-qa.herokuapp.com>  

That’s it for this task.

Note however, that if/when you need to deploy other branches to the qa site, this is the syntax:

git push heroku-qa my-feature-branch:main

You should typically announce this on the team’s slack channel before pushing; this helps to avoid conflicts where two team members push to -qa at the same time.

If that becomes a bottleneck, you can create as many additional -qa deployments as you need. They will need to be added to the list of authorized redirect URIs on Google OAuth (or else you’ll need to create a separate OAuth Client Id and Client Secret value for each one.)