### Continuous Integration <iframe src="https://giphy.com/embed/8EmeieJAGjvUI" width="480" height="360" frameBorder="0" class="giphy-embed" allowFullScreen></iframe> How can we use GitHub Actions to automatically run our tests and deploy our code? --- ### Questions to consider 1. What is continuous integration (the methodology)? (Sasha) 2. What is a continuous integration *server*? (Mohamed) 3. Why might we want to run our tests whenever we push code to our repo? (Micheal) 4. A&Q --- ### Useful resources - [About continuous integration | GitHub Actions](https://help.github.com/en/actions/building-and-testing-code-with-continuous-integration/about-continuous-integration) - [Understanding how to use GitHub Actions)](https://zellwk.com/blog/understanding-github-actions/) --- #### What *is* Continuous Integration? - Methodology that relies on frequent commits and semi-automated testing - In short: less debugging, more time to wrote code - Pros: Accurate recording of changes, easier to merge branches - Cons: Requires additional servers, developing test procedures kind of a time sink, if you do it wrong everything will suck. --- #### *How* is Continuous Integration? - CI can run on a set schedule, or when a GitHub action occurs. - You can use CI to auto test, and auto-lint your code.  --- #### How do you set up CI? The Github docs page is Kind Of A Mess NAME ON JOBS ``` name: first-github-action on: [push] jobs: write-to-console: runs-on: ubuntu-latest steps: - run: echo 'Hello world!' ``` --- A continuous integration server (sometimes known as a build server) essentially manages thecode coming in. The CI (Heroku continuous development) server initiates a build and documents the results of the build.  <!-- Travis CI is a hosted[2] continuous integration service used to build and test software projects hosted on GitHub[3] and Bitbucket.[4] Travis CI was the first CI service which provided services to open-source projects for free and continues to do so. TravisPro provides custom deployments of a proprietary version on the customer's own hardware. The source is technically free software and available piecemeal on GitHub under permissive licenses. The company notes, however, that the large number of tasks that a user needs to monitor and perform can make it difficult for some users to successfully integrate the Enterprise version with their own infrastructure.[5] --> --- Building server Building and testing your code requires a server. You can build and test updates locally before pushing code to a repository, or you can use a CI server that checks for new code commits in a repository.  --- Github CI GitHub runs your CI tests and provides the results of each test in the pull request, so you can see whether the change in your branch introduces an error. When all CI tests in a workflow pass, the changes you pushed are ready to be reviewed by a team member or merged. When a test fails, one of your changes may have caused the failure.  <!-- When you set up CI in your repository, GitHub analyzes the code in your repository and recommends CI workflows based on the language and framework in your repository. For example, if you use Node.js, GitHub will suggest a template file that installs your Node.js packages and runs your tests. You can use the CI workflow template suggested by GitHub, customize the suggested template, or create your own custom workflow file to run your CI tests. If you enable email or web notifications for GitHub Actions, you'll receive a notification when any workflow runs that you've triggered have completed. The notification will include the workflow run's status (including successful, failed, neutral, and canceled runs). You can also choose to receive a notification only when a workflow run has failed. --> --- ##### Why might we want to run our tests whenever we push code to our repo? - We may want to run our tests everytime we push code to **spot errors** before we merge it to the main branch. --- ##### Why might we want to run our tests whenever we push code to our repo? - With Continuous Integration in GitHub Actions this becomes easy. <!--As previously mentioned, GitHub runs your CI tests and provides the results of each test in the pull request, so you can see whether the change in your branch introduces an error.--> - ✔ When all CI tests in a workflow pass, the changes you pushed are ready to be reviewed by a team member or merged. - ❌ When a test fails, one of your changes may have caused the failure. --- ##### Why might we want to run our tests whenever we push code to our repo? - This is why it is also important to do "atomic" commits - where pretty much every change is committed, so we can see errors before we have a large amount of changes to deal with. ```javascript function add(a,b){ return à + b; } add(1,2) function multiply (a,i) { return a * ¡; } multiply(2,3) ``` --- ### Any Questions <iframe src="https://giphy.com/embed/xT0xeuOy2Fcl9vDGiA" width="480" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe>