Visual Studio Code (VS Code) is one of the most popular and widely used code editors in the world. It has gained significant popularity in the developer community due to its flexibility, extensive ecosystem of extensions, and strong community support.

VS Code has a high level of integration with GitHub. It offers features such as Git integration, the synchronization of your settings using your GitHub account, direct access to repositories, and the ability to create, edit, and manage GitHub Action workflows from within the editor using the extension provided by GitHub. This tight integration simplifies the workflow creation process and streamlines collaboration on GitHub action workflows.

In this recipe, we’ll install the VS Code extension for GitHub Actions and inspect what you can do with it.

Getting ready…

Before we begin, check that your email address and name are set correctly in Git:

$ git config --global...

Starting in a greenfield repository, it is best to create your workflows on the main branch. However, if you must create the workflow in an active repository that developers are working in and you don’t want to get in their way, then it is possible to write workflows in a branch and merge them back to the main branch using a pull request.

However, some triggers might not work as expected. If you want to run your workflow manually using the workflow_dispatch trigger, your first action must be to merge the workflow with the trigger back to main or use the API to trigger the workflow. After that, you can author the workflow in a branch and select the branch when triggering the workflow through the UI.

If your workflow needs webhook triggers, such as push, pull_request, or pull_request_target, it might be necessary to create the workflow in a fork of the repository, depending on what you plan on doing with the triggers. This way, you can test...

In this recipe, we’ll add a linting action that will check the workflow and give feedback directly in the pull request.

Getting ready…

Open the workflow file in the branch that you have for the open pull request. Do not merge the changes yet.

How to do it…

1. Go to the marketplace and search for the actionlint. The action we are looking for is from devops-actions. The action needs to access the workflow files, meaning you have to check out the repository using the checkout action first. Add the following two steps to the end of the job:

   - uses: actions/checkout@v4.1.0
   - uses: devops-actions/actionlint@v0.1.2

2. As we want the action to annotate errors in pull requests, we have to give the workflow write access to pull requests. I’ll explain later how this works. For now, just add a section permissions to the job like this:

   jobs:
     job1:
       runs-on: ubuntu-latest
       permissions...

What problem matchers do based on existing result files can also be achieved by writing individual warning or error events to the log by also using workflow commands. In this recipe, we will add some output to our workflow and annotate our workflow file.

Getting ready…

Make sure you still have your pull request from the previous recipe open. Just use VS Code to add additional changes, and pushing will automatically trigger the workflow.

How to do it…

1. Open .github/workflows/DevelopInBranch.yml in the new-workflow branch in VS Code and add the following code snipped directly before the checkout action:

         - run: |
             echo "::debug::This is a debug message."
             echo "::notice::This is a notice message."
             echo...

In the previous recipe, we saw that you can rerun failed jobs or all jobs with debug logging enabled. However, you can also enable or disable debug logging on a repository base.

How to do it…

We can enable or disable debug logging by adding a variable called ACTIONS_STEP_DEBUG to our repository and setting the value to true or false. This will add a very verbose output to our workflow logs and all debug messages, and this will be displayed from all actions.

You can configure the variable using the web, the GitHub CLI, or VS Code. To set the variable using the web, in the repository, navigate to Settings | Secrets and variables | Actions and pick the Variables tab (/settings/variables/actions). Click New repository variable (which will redirect you to /settings/variables/actions/new), enter ACTIONS_STEP_DEBUG as the name, true as the value, and click Add variable.

To set it using the CLI, just execute the following line:

$ gh variable set...

Committing workflows every time and running them on the server can be a slow process, especially for complex workflows. In this recipe, we will learn how to run a workflow locally using act (https://github.com/nektos/act).

Getting ready…

Act depends on Docker to run workflows. Make sure you have Docker running.

You can install act using different package managers (see https://github.com/nektos/act#installation-through-package-managers). Just pick the one that fits your environment and follow the instructions.

When running act for the first time, it will ask you to choose a Docker image to be used as the default. It will save that information to ~/.actrc. There are different images available. There are small images available (node:16-buster-slim) that will only support NodeJS and nothing more. The big images are more than 18 GB in size. Keep that in mind. However, with today’s disk space and internet, you will get the best results...