Landing Page for /actions/getting-started

GitHub Actions help you automate your software development workflows in the same place you store and collaborate on code. Individual actions are reusable pieces of code that let you build, test, package, or deploy projects on GitHub. But you can also use them to automate any step of your workflow.


<h3 style="padding-bottom: 15px; color: #586069;">
 How to get started in four simple steps
</h3>

<ol>
 <li>Click the “Actions” tab in your repository 
 GitHub Actions is tightly integrated with your code and with the rest of the experiences on GitHub.
 </li>
 <li>Choose the workflow that’s best for your type of project 
 GitHub Actions offers helpful workflow templates to get you started, including templates for Node.js, Rust, .NET Core, and more.
 </li>
 <li>Customize your workflow 
 You can start with the workflow templates that we provide, and then you can customize them to your project’s exact requirements.
 </li>
 <li>Once you’ve chosen your workflow, press the “start commit” button 
 Your workflow configuration lives in your repository, so the build definition is versioned alongside the finished code.
 </li>
</ol>

 GitHub Actions guide: <a href="https://help.github.com/en/actions">https://help.github.com/en/actions</a>
 
 Questions and answers on GitHub Actions: <a href="https://github.community">github.community</a>


<h3 style="padding-bottom: 15px; color: #586069;">
 Helpful terms to know
</h3>

 Action 
 A program that becomes a reusable component to be used in workflows. Actions can install software for the environment, set up authentication, or automate complex sets of tasks. You can find actions in the GitHub Marketplace, or create your own and share them with your community.
 

 Workflow 
 A configurable, automated process that you can use in your repository to build, test, package, release, or deploy your project. Workflows are made up of one or more “jobs” and can be triggered by GitHub events.


 Continuous integration (CI) 
 The software development practice of frequently committing small code changes to a shared repository. With GitHub Actions, you can create custom CI workflows that automatically build and test your code. From your repository, you can view the status of your code changes and detailed logs for each action in your workflow. CI saves developers time by providing immediate feedback on code changes to detect and resolve bugs faster.


 YAML 
 YAML stands for “Yet Another Markup Language”. It’s a human-readable markup language commonly used for configuration files, especially by CI- and <a href="https://resources.github.com/devops">DevOps</a>-focused software tools. GitHub Actions uses YAML as the basis of its configuration workflows.


 Workflow file 
 The configuration file that defines your GitHub Actions workflow. This is written in YAML and lives inside your GitHub repository in the .github/workflows directory. Each file in that directory that is named with a .yaml extension will define a unique workflow.


<h3 style="padding-bottom: 15px; color: #586069;">
 Example workflow file
</h3>

```yaml
name: CI for Node.js Project
on:
 push:
 branches: [ master ]
 pull_request:
 branches: [ master ]
jobs:
 build:
 runs-on: ubuntu-latest
 name: Build and Test
 steps:
 - uses: actions/checkout@v2
 name: Check out repository
 - uses: actions/setup-node@v1
 name: Set up Node.js
 with:
 node-version: 12
 - run: |
 npm ci
 npm run build
 npm test
 name: Build and Test
```

<h4>
 An explanation of this example workflow:
</h4>

 name 
 The name of your workflow will be displayed on your repository’s actions page.


 on 
 The events that occur on GitHub that will cause your workflow to be executed. For example, you can run your workflow on push and pull_request triggers, which will let you build your code and run your tests in a <a href="https://resources.github.com/ci-cd">Continuous Integration</a> workflow. You can add additional constraints on these triggers, like running when certain files or changed or when a certain branch is pushed to.


 jobs 
 A list of the jobs that run as part of the workflow. Each job will run independently of the others, and will run on a different virtual environment. Jobs may have a name to make them easily identifiable in the UI or in logs. Jobs contain a set of steps that will be executed, in order. This workflow has a single job, the build job.


 jobs.&lt;job-id&gt;.runs-on 
 The type of runner to use to run the given job on, either a runner provided by GitHub or a self-hosted runner that you configure. GitHub provides three main types of runners: Linux (named ubuntu-latest), Windows (named windows-latest) and macOS (named macos-latest).


 jobs.&lt;job-id&gt;.steps 
 A list of the steps that will run as part of the job. Each step will run one after another, all on the same virtual environment. By default, if any step fails then the entire job will stop. In this workflow, the build job contains three steps:
 <ol>
 <li>
 The first step uses an action named actions/checkout@v2. This is an action provided by GitHub that will check out your repository onto the runner, so that it can be built and tested.
 </li>
 <li>
 The second step uses an action named actions/setup-node@v1. This is an action provided by GitHub that will set up a particular version of Node.js on the runner. Arguments can be provided to the action in the with section; in this example, the node-version argument is set to 12, which instructs the action to put Node.js version 12 in the PATH for subsequent steps.
 </li>
 <li>
 The final step runs programs on the command-line. By default, these programs will be run with bash (on Linux and macOS) or PowerShell (on Windows). A single command may be specified, or multiple commands can be specified by starting them with a leading pipe (|) symbol.
 
 In this case, a Node.js continuous integration build will be performed by running npm ci to download and install packages from the npm registry, then running npm run build to run the build script specified by the project, and finally running npm test to run any unit tests in the project.
 </li>
 </ol>

Everything you need to know about getting started with GitHub Actions

Resource Page for /actions/github-actions-cheat

GitHub Actions Cheat Sheet

By: Angela Jiang, Product Marketing Manager @Sentry

*[Sentry](https://sentry.io/welcome/) is an application monitoring platform that helps over 3.5 million developers see what actually matters, solve quicker, and learn continuously about their applications - from the frontend to the backend.*

<h2> Toolchains are complicated—developers and engineering managers are working with more tools than they probably care to count. In order to maintain efficiency in today’s world, having smart integrations in place is becoming less of a nice-to-have and more of a necessity.</h2>

At Sentry, we're focusing on [improving the developer workflow](https://blog.sentry.io/2022/05/06/workflow-2-0) and that means in part building deeper integrations with tools like Github to make it easier for developers to monitor every stage of the release cycle - giving developers a more automated deployment workflow to catch errors as quickly as code is shipped to production (with no superfluous button-clicking).

Whether you’re already using Sentry and GitHub separately, or building a deployment workflow for the first time, you can follow these steps to create an automated workflow for your team:

 - [Sign in](https://sentry.io/auth/login/) to your Sentry account
 - Connect your [GitHub repositories to Sentry](https://docs.sentry.io/product/integrations/source-code-mgmt/github/) to begin tracking commit data
 - Import your GitHub CODEOWNERS file to [automatically map issues](https://docs.sentry.io/product/issues/issue-owners/#code-owners) to teams or people in Sentry
 - Install the [Sentry Release GitHub Action](https://github.com/marketplace/actions/sentry-release) in GitHub to automatically upload sourcemaps, manage releases in Sentry and track how the release is trending

Customers like [Forethought](https://forethought.ai/), who have growing engineering teams and are shipping continuously, often operate with limited visibility into the code they ship and ownership over who should fix what once it's released. In Forethought’s case, integrating their GitHub CODEOWNERS file with Sentry allowed them to divide up and assign responsibilities to specific teams, [reducing their time to resolution by up to 94%](https://blog.sentry.io/2022/05/02/an-engineering-managers-tips-for-scaling-teams#defining-roles).

In addition to improving issue ownership, integrating GitHub with Sentry allows customers like Forethought to: 
- Automatically monitor the health of a new release and its impacts on users with Sentry Release GitHub Actions
- Create or link GitHub issues directly in Sentry
- Predict which commit caused an issue and who is likely responsible to resolve it
- Link Sentry stack traces back to the GitHub source code to see the line of code causing an error
- Resolve issues via a pull request or commit

Let’s walk through an example of how customers typically use Sentry and GitHub together and how you can see the above in action.

After a release is deployed, you head into your [Release Health](https://docs.sentry.io/platforms/android/configuration/releases/#release-health) tab within Sentry to monitor the stability, user adoption, and issues in a release so you can identify and stop the roll out of a bad release before it impacts customers. Within Release Health, you will see historical commit details and key stats like user adoption, application usage, and crash-rates. You can also view new, unhandled, regressed issues, and related performance problems in each release. 

![Sentry screen shot](//images.ctfassets.net/wfutmusr1t3h/6B01Y7E1ynj59MPXSjHGTq/09072f16a26588f0225dcdd20f8bc188/Sentry4.png)

With the [Sentry Release GitHub Action](https://github.com/marketplace/actions/sentry-release) installed, every new release (major or minor) will be automatically recorded and [suspect commits](https://docs.sentry.io/product/cli/releases/#sentry-cli-sourcemaps) automatically configured. Sentry will also upload the original, untransformed source code (aka [sourcemaps](https://docs.sentry.io/product/cli/releases/#sentry-cli-sourcemaps)) which un-minifies any Javascript code that is present. You can see when a release is not trending well by looking at key metrics such as the user adoption and crash-free session rate. 

![Sentry image 1](//images.ctfassets.net/wfutmusr1t3h/6BynkLIwSS0z6L3GHO3CS0/e245a166103fb599c05df87db8f0d190/Sentry1.png)

With the GitHub CODEOWNERS file synced to Sentry’s Code Owners rules, Sentry will not only capture the issue impacting users, but will also surface the specific commit related to the issue and automatically suggest the right team member to triage the issue. This way, you no longer need to scramble to figure out who is responsible for what when critical outages occur. 

![Sentry image 2](//images.ctfassets.net/wfutmusr1t3h/6sNxO3E0qkiqcN57Ghjbi5/9d2ecb917889876a783e95016d087573/Sentry2.png)

From here, you can create a GitHub issue directly from Sentry and tag the suggested assignee to an issue.

![Sentry screen shot ](//images.ctfassets.net/wfutmusr1t3h/1mWMC7oNxUPQkSoRnS7VLq/9c68b750edb78a21e5e0e96c65b39c7a/sentry5.png)

By clicking into the Sentry error report, the developer assigned to the issue can see the stack trace and easily navigate to the relevant GitHub file that is deep linked in the stack trace to investigate the issue further. 

![Sentry screen shot](//images.ctfassets.net/wfutmusr1t3h/2GOLy1bEkMUT2PiL2D1idr/7a2b4e84ee30c62e00f7a5e3c3fc61d8/sentry6.png)

Lastly, the developer who owns the issue can quickly identify what the problem is, fix it, and open a pull request with the Sentry Issue ID included in the comments. (Sentry automatically annotates the matching issue with a reference to the commit or pull request, and, later, when that commit or pull request is part of a release, mark the issue as resolved). 

![Sentry image 3](//images.ctfassets.net/wfutmusr1t3h/5upZY2BsVxt515vikOkZqM/357c4b2f2e7154abdb90e81c3c043b84/Sentry3.png)

By integrating GitHub with Sentry, you will be able to unlock the full potential of both tools to simplify your team’s workflow, increase speed to resolution, and learn from trends to optimize code health over time. 

As we continue to strive to improve how developers ship and improve software, [we'd love to hear from you](https://github.com/getsentry/sentry/issues/34327)-what part of the workflow works well, what is completely terrible, and what can we do better?

New to Sentry and want to try it out for free? [Sign up](https://sentry.io/signup/) or try out the latest version of the Action [here](https://github.com/marketplace/actions/sentry-release).

Whether you’re already using Sentry and GitHub separately, or building a deployment workflow for the first time, you can follow these steps to create an automated workflow for your team

Resource Page for /actions/integrating-with-sentry

Integrating GitHub with Sentry to Increase Speed to Resolution 

Join us as we explore GitHub Actions and implement a build, test, and deploy with powerful CI/CD capabilities right next to your code.

The image features a dark background with security-themed shapes in the top left and bottom right corners. The centered text reads "What is GitHub Actions?"