The First Automation: Fetching Issues from GitHub

In our previous lesson, we met Alex, a developer whose focus is constantly drained by the “triage tax” of managing GitHub issues. This manual, repetitive work is a perfect candidate for automation. In this lesson, we will move from theory to practice and build the first version of our solution. Before we dive in, there are some key concepts that we need to familiarize ourselves with.

Workflows, nodes, and “workflows as code”

Before we jump into building, let’s define the core components of the n8n ecosystem. As a developer, you’ll find these concepts map closely to paradigms you already know:

• Workflow: A workflow (shown in an orange box) is the central concept in n8n. It is an executable process that consists of a series of connected nodes. Think of it as a single, stateful script or a lightweight microservice. It starts with a trigger and processes data through a sequence of steps. The visual representation of a workflow lives on the canvas (shown in a purple box).

• Node: A node is a reusable, functional block that performs a specific action. In a traditional programming language, you can think of a node as a function call or a library import. It takes data as input, performs an operation, and produces an output. There are three main types of nodes:

  • Trigger nodes: These nodes (shown in a red box) always start a workflow. They listen for a specific event, like a webhook call, a schedule (cron job), or a new message in a queue.

  • App nodes: These are pre-built integrations (shown in a green box) for specific services like GitHub, Slack, Jira, or PostgreSQL. They handle the authentication and API calls for that service, abstracting away the boilerplate.

  • Core nodes: These are logic and data processing nodes that are not tied to a specific app. They include nodes for branching (If, Switch), looping (Loop Over Items), and writing custom code (Code).

• Connection: A connection (shown in a yellow rectangle) is the data pipe between two nodes. It directs the output of one node to the input of the next. The data that flows through these connections is structured as an array of JSON items, making it easy to parse and manipulate.

• Expression: An expression is a small snippet of JavaScript, wrapped in {{ }}, that allows you to dynamically access and manipulate data within a node’s parameters. For example, instead of a static message in a Slack node, you can use an expression like New GitHub issue created: {{ $json.body.title }} to insert the title from a previous node.

Finally, the concept that ties all of this together for a developer is workflows as code. While you build workflows on a visual canvas, the underlying definition of every workflow is a JSON object. This means you can export, save, and manage it with the same tools you use for your application code. This approach gives you the best of both worlds: the rapid development and clarity of a visual interface, combined with the power, control, and discipline of professional software engineering practices.

Creating the MVP

Our objective is to create a functioning, three-node workflow that serves as a Minimum Viable Product (MVP). This initial version will be manually triggered. When executed, it will fetch open issues from a designated GitHub repository and post a simple, static notification to a Slack channel. It’s a straightforward proof-of-concept that lays the foundation for the intelligent agent we will build throughout this course.

To achieve this, we will use three core components:

• The manual trigger, to start our workflow on demand.

• The GitHub node, to interact with the GitHub API.

• The Slack node, to send notifications.

Let’s begin by setting up our development environment: the n8n canvas.

The n8n canvas: Your visual IDE

First, let’s get acquainted with the n8n user interface. The central workspace where you will build, connect, and configure nodes is called the canvas. For a developer, it’s useful to think of the canvas as a visual Integrated Development Environment (IDE) for creating automated services.

To start, create a new, blank workflow. From your n8n dashboard, select the “Create Workflow” button. This will open a new canvas containing a single starting point: the “Add first step...” button.

Selecting this button opens the nodes panel, which is your library of available integrations and functions. From here, you can search for the specific tools you need.

Our first step is to add a trigger. In the nodes panel, you should see the manual trigger; if not, you can search for it and select it. This will place our first node on the canvas.

Securely storing API keys in credentials

Nodes that access external services, like GitHub or Slack, in our case, often require some form of authentication. A common but insecure practice is to paste secrets directly into code or configuration files. n8n provides a much safer and more manageable solution.

A credential in n8n is a secure, stored set of authentication details for a third-party service. Instead of managing secrets in files or environment variables, you create a credential in n8n’s encrypted storage. When you configure a node, you simply select the credential you want to use, and n8n handles the rest.

Creating the GitHub credential

1. Generate a GitHub Personal Access Token (PAT):

   1. Navigate to your GitHub account settings and select “Developer settings > Personal access tokens > Tokens (classic).”

   2. Select “Generate new token (classic).”

   3. Give your token a descriptive name, like n8n_triage_agent.

   4. Set an expiration date.

   5. Under “Select scopes,” check the box for repo. This grants the token permission to access your repositories. You can find more details in the official GitHub documentation on creating personal access tokens.

   6. Generate the token and copy it immediately.

2. Create the credential in n8n:

   1. For the top bar in the canvas, click the “+” button to create a credential in your personal account.

   2. Select “GitHub API” in the drop-down.

   3. Add your username in the “User” field.

   4. Paste the Personal Access Token you copied from GitHub into the “Access Token” field.

   5. Click the “Save” button.

Our GitHub credential can now be used across our workspace for any node that needs to connect with GitHub.

Creating the Slack credential

1. Generate a Slack Bot Token:

   1. Go to the Slack API Apps page and select “Create New App.” You might need to log in before you can access the API apps page.

   2. Choose “From scratch,” give your app a name (e.g., n8n Triage Agent), and select the workspace to install it in.

   3. Once the app is created, navigate to “OAuth & Permissions” in the sidebar.

   4. Under “Scopes > Bot Token Scopes,” add the chat:write permission. This allows the app to post messages in channels.

   5. At the top of the page, select “Install to Workspace” and authorize the installation.

   6. Copy the “Bot User OAuth Token” that is generated.

   7. Go back to “Basic Information” from the sidebar and copy the “Signing Secret” as well.

2. Create the credential in n8n:

   1. Similar to how we added GitHub credentials to n8n, create a credential for the Slack API as well. Go to n8n, click the “+” button, select “Credentials,” select “Personal,” and select “Slack API” from the drop-down menu.

   2. Paste your Bot User OAuth Token as the “Access Token.”

   3. Under the “Signature Secret,” paste your “Signing Secret” that you copied earlier.

   4. Optionally, you can give your credential a name and save it.

Configuring your first app node

With our trigger in place and the credentials taken care of, we can now build the core logic of our MVP. This involves fetching data from one service (GitHub) and sending it to another (Slack).

Fetching data with the GitHub node

First, we need to get the issues from our repository.

1. Select the “+” icon on the right side of the manual trigger node. The nodes panel will open.

2. Search for the GitHub node. Selecting this node will open a sublist of actions.

3. Search for “issues” and choose the “Get issues of a repository” action.

4. The configuration panel for the GitHub node will open. This is where you set the node’s parameters to define its behavior. You will notice that n8n has already added our GitHub account to the credential drop-down.

5. Configure the parameters for our desired action:

   1. Resource: Repository

   2. Operation: Get Issues

   3. Repository owner: Enter the username of the repository owner (for example, n8n-io).

   4. Repository name: Enter the name of the repository (for example, n8n).

   5. Limit: Set the limit to 5 to fetch a maximum of 5 issues from the repository

6. You can exit this configuration panel by pressing the escape key or clicking “Back to canvas” at the top left of your screen.

Your GitHub node is now configured to fetch all issues from the specified repository.

Testing the GitHub node

You might be tempted to run your workflow right now, and while that might work, a better approach would be to test this individual node before moving it forward. This “test before you deploy” workflow should be a default behaviour if you’re working on serious projects. n8n offers a few features that make this entire process easy. Let’s see how.

1. Click the node to open the configuration panel if you have closed it. From here, you can use the “Execute step” button to run the node.

2. Running the node should fetch 5 issues from the repository.

3. You will see three tabs in the output section: Schema, Table, and JSON.

   1. The Schema view shows all the different keys from the input and provides an example of their corresponding values.

   2. The Table view provides a user-friendly, spreadsheet-like summary of the output data. It’s useful for quickly scanning results.

   3. The JSON view shows the raw data structure exactly as it was returned from the API. For developers, this is the “source of truth.” It reveals the precise field names and nesting of the data, which is essential for debugging and for writing the dynamic expressions we will cover in a later lesson.

4. Normally, if you’re working with tools that rely on external data, testing can be cumbersome as you can often hit rate limits or incur costs. n8n has you covered. It allows us to pin an output to a node. Doing so will make the node always return the pinned output without having to run the node.

5. For now, you can pin the output to the GitHub node.

Sending notifications with the Slack node

Next, we will send a notification about the issues we’ve fetched.

1. Select the “+” icon on the GitHub node.

2. Search for the “Slack” application and select it.

3. From the actions sub-menu, choose the “Send a message” action.

4. Once the configuration panel is open, configure the node’s essential parameters:

   1. Channel: Select the channel where you want to post the notification. You can enter the name of a public channel (e.g., test-channel) or an ID for a private channel.

   2. Text: Enter a static message for now. Something simple like “New GitHub Issue Detected” will work. We will make this message dynamic in a future lesson.

Our workflow structure is now complete. If you execute this step, you should see a few (five to be exact) messages in your Slack application.

Running the workflow and inspecting the data flow

With our nodes configured and authenticated, our MVP is complete. It’s time to execute it in its entirety and see the data in motion.

At the bottom left of the canvas, select the “Execute Workflow” button. n8n will execute the nodes in sequence. You can watch the progress as each node completes. A successful execution will show a green checkmark and an item count above each node.

Here’s the workflow file we have so far. You can also visualize it in the widget below:

What’s next?

You have successfully built your first functioning automation in n8n. In this lesson, we have:

• Constructed a three-node workflow on the n8n canvas.

• Configured app nodes with the necessary parameters to interact with APIs.

• Securely stored and used API tokens with n8n credentials.

• Executed a workflow and inspected its data flow using both the Table and JSON views.

Our developer, Alex, now has a working MVP. It’s a simple tool, but it’s a solid foundation. The biggest limitation is that it’s still manual; Alex has to click a button to run it.

In the next lesson, we’ll make our agent fully autonomous by replacing the manual trigger with a real-time webhook, so the workflow runs instantly when a new GitHub issue is created.