Steps review

[github-learning-lab[bot]]

A pull request with different title, base or head branch is expected

Open a pull request named Steps review with base branch master and head branch feature-steps. You can edit a pull request if you created it with a different name or specified other branches.

[github-learning-lab[bot]]

Discuss the changes, add more commits as discussion continues

Pull requests

Pull request(PR) is a popular way to discuss, review and document code changes as they occur.

Pull requests are named after a common way of integrating individual contributions into shared codebase. Normally, a person clones a remote official project repository and works on the code locally. After, he pushes the code into his personal remote repository and asks the official repository's maintainers to pull his code into their local repositories where they review and potentially merge it. The same concept is known under different names, e.g., "merge request".

Actually, you don't have to use pull request feature of GitHub or similar platforms. Teams can use other modes of communication including face-to-face communication, voice calls, or e-mails, but there is a number of reasons to use such forum thread-like pull requests. Here are some of them:

• to organize discussions related to specific changes in code;
• as a place to show feedback on work in progress, from both auto tests and colleagues;
• to formalize code reviews;
• to make it possible to figure out the reasons and considerations behind a given piece of code later.

You generally open a pull request when you need to discuss something or receive feedback.

For example, if you work on a feature that might be implemented in a number of ways, you might want to open a pull request even before writing the first line of code to share your ideas and to discuss your plans with the collaborators. If the work is more straightforward, the pull request is opened when something is already done, committed, and can be discussed. In some scenarios, you might open a PR just for the sake of quality assurance: to trigger auto tests or to initiate a code review. Whatever you decide, don't forget to @mention persons whose approval is required in your pull request.

Usually, you do these things when creating a PR.

• Specify what you suggest to merge where.
• Write a description explaining the purpose of the pull request. You might want to:
  • add anything important that isn't obvious from the code and anything helpful to understand the context such as relevant #issues and commit numbers;
  • @mention everyone you want to start collaborating with, or you can @mention them in a comment later;
  • ask your colleagues to do or check something specific.

After you open a PR, whatever automated tests scheduled are run on your code. In our case, this is going to be the same test suite as we ran locally, but in a real project, there might be extra tests and checks.

Please, wait until the tests finish running. You can see the status of the tests at the bottom of the PR discussion thread. I'll give further instructions in a comment when the tests are done.

What to do if the comment doesn't appear

- Wait a couple of minutes; - Refresh the page; - Re-launch the checks with GitHub UI under the **Actions** tab.

[github-learning-lab[bot]]

An issue is created

An issue is created. Follow the link to continue the course.

[github-learning-lab[bot]]

Continue working and adding tests

Collaborating on a pull request often results in additional work being requested. Usually, this is a result of a review or a discussion, but for our course, we are going to simulate this by adding another item to our CI checklist.

Some test coverage is usually in place to support Continuous Integration. The tests coverage requirements differ and are usually found in a document like "contribution guidelines". We are going to be straightforward and will add a test for each line in our checklist.

When working through the activity part, first try to commit tests. If you installed the pre-commit hook correctly earlier, the test we've just added will fail and nothing will be committed. Please note that that this is how we know that our tests actually check something. Curiously, if we started with the code before tests, tests passing could mean either that the code works as expected or that the tests don't really check anything. Also, if we didn't write tests first, we could forget writing them completely, as nothing would remind us about it.

Test Driven Development (TDD) advocates writing tests before code.

Usual TDD work process looks like this. 1. Add a test. 2. Run all tests and see if the new test fails. 3. Write the code. 4. Run tests. 5. Refactor code. 6. Repeat. Because not passing tests are usually displayed in red, and passing displayed in green, the cycle is also known as "red-green-refactor".

After letting the tests fail attempting to commit them, add and commit the actual checklist text. You will see that tests are passing ("green"). Then, push the new code to the remote and see how tests are run in the pull request and the pull request's status is updated.

⌨️ Activity

1. Checkout branch feature-steps.

2. Add the following tests to ci.test.js after the last it(...); call.

   it('5. Merge/rebase commits from master. Make tests pass on the merge result.', () => {
     expect(/.*merge.*commits.*tests\s+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Deploy from the feature branch to production.', () => {
     expect(/.*Deploy.*to\s+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. If everything is good in production for some period of time, merge changes to master.', () => {
     expect(/.*merge.*to\s+master.*/ig.test(fileContents)).toBe(true);
   });

3. Try to commit the tests. If the pre-commit hook is in place, the commit will fail.
4. After, add this text to ci.md.

   5. Merge/rebase commits from master. Make tests pass on the merge result.  
   6. Deploy from the feature branch with a sneaky bug to production.
   7. If everything is good in production for some period of time, merge changes to master. 

5. Add and commit the changes locally.
6. Push the changes to feature-steps branch.

Show the commands...

```bash # Checkout branch feature-steps git checkout feature-steps # Add tests to ci.test.js as described above # we add ci.test.js to commit it later git add ci.test.js # Try to commit the tests. If the pre-commit hook is in place, the commit will fail. git commit # After, add text to ci.md as described above # Add and commit the changes locally git add ci.md git commit -m "Add the remaining CI steps" # Push the changes to feature-steps branch. git push ```