Free Resources
Fullstack AWS with AWS Amplify
Recommended Articles
Creating Your Own GitHub Action With TypeScript
In a recent JavaScript Marathon live training by Software Engineer Chris Trześniewski, viewers learned how to create their own GitHub Action using Typescript. If you would like to watch this training for yourself, you can check out this JavaScript Marathon training on YouTube. I also invite you to follow along as I review the major points covered in this training with code examples that you can implement right now! What is a GitHub Action? A GitHub Action allows users to simply run a script, and automatically run jobs or workflows on a repository. These jobs and workflows can be triggered by events like merging to a branch, pull requests, push updates, and more. Activities we can automate with GitHub Actions include linting, testing, building, and project deployment on every push to the main branch. Below is a step-by-step process for creating your own GitHub Action using Typescript! Let's begin by setting up our project! Project Setup Setting up the project environment is an essential first step. Use this repository as a starter, which is what Chris used for his presentation. First, run git clone https://github.com/ktrz/gh-action-js-marathon to clone the repository into a local directory. Then, change into directory with cd gh-action-js-marathon, using npm to install dependencies, and run the build script. To initialize a node project in the directory, run the npm command: ` At this point, you will accept the properties. However, since the project is in TypeScript, it will have to be compiled into JavaScript before building the entry point, which will be dist/index.js. After this, you will continue installing dev-dependencies like @types/node. To do this, run: ` To set up the TypeScript project, include a tsconfig.json to let TypeScript know where the source files are, and where the output directory will be. You can use the below configuration with a little extra configuration for this project. tsconfig.json file ` The line "outDir": "dist" tells the TypeScript compiler that the output files should go into the dist directory. tsconfig.build.json file ` The lines "include": ["src//*.ts"], and "exclude": ["src//*.spec.ts"] tell the TypeScript compiler to ignore any file name that ends with spec.ts, and to include every file that ends with .ts in the src directory. The next step is to edit the package.json file, replacing the test script with a build script "build": "tsc -p tsconfig.build.json". To test the build script, create an src directory, and create an index.ts file with the following code inside it: ` Then, run the script npm run build, which builds the TypeScript code, and generates a JavaScript file for the project. To clean up, add a gitignore file. Use the below content for the file: ` GitHub Action Set Up Continue by creating a GitHub Action file, which is a YML extension file named action.yml. This will define what the project, and the entry file for the GitHub Action configuration, are. action.yml file ` Details above properties name, author, and description include the metadata for the yml action file. The run property is the most important part of the configuration. It informs developers of what to use to run the Action. For this project, it is Node 16. The directory for the Action is the same as the build script directory, which is dist/index.js. In this case, if we build and deploy the Action to a separate branch on the repository, this should allow anyone to point to the repository and use the Action. For the purposes of this training, we will set up all of this in one directory. This will be a .github/workflow directory in the repository, in which we will create a test Action with the below configuration: .github/workflow/test.yml file ` Using the properties here, we will first need to define a name for the Action, which is Test. Then, we define what triggers the workflow, which is where the on property comes in. Following this, we will create either a push to main or a pull request that is created against the main branch. On the jobs property, we define a map of jobs that we want to run. This will have the name property for displaying the name of what we are running. Here, we want to run the Linux Virtual Machine environment provided by GitHub. Next, check out the repository: - uses: actions/checkout@v2. This is an out-of-the-box GitHub Action provided by GitHub. Then, we set up a node environment to run the actual script for our project on the line uses: actions/setup-node@v2. This installs node-version 16, and then caches npm so it doesn’t take as long on a subsequent run. Install the project dependencies using command npm ci, which is the same as the usual npm install. However, npm ci is used to install all exact version dependencies, or devDependencies from a package-lock. Now it's time to build our project with the run property run: npm run build. Finally, we will point to a directory in the project. For our case, it is the current working directory, and GitHub will find the action.yml file there. GitHub will be able to identify the entry point as we defined it in the action.yml. To test for a pull request trigger, you can create another branch and call it feat/setup-action. Publish the new branch, navigate to the remote repository, and create a pull request. This should trigger the workflow to run. GitHub Actions Dependency Now it's time to install some dependencies from GitHub. These dependencies allow you to retrieve information about the event that triggered the action from GitHub Runner. Run the npm installation command npm install @actions/core @actions/github. Edit the src/index.ts file to replace it with the code below: ` Now, you should modify the action.yml file, and add the below code. The final file should look like this: ` Commit the changes and push to the remote repository. The workflow will trigger and run again. You should see ’Hello JS Marahon viewers!’ on the line Run my action. This is for default values. But you can also provide values on the Actions by editing the .github/workflow/test.yml file. The final file should look like this: ` Commit the code, and push to the remote repository. On line 4 of Run my action, you will see the new message to the sponsor. Retrieve Data To retrieve data from GitHub, we will use the second dependency. This time, modify src/index.ts. The file should look like this: ` Import context, which is the object that will be provided by the Action runner, to get basic data about the repository that we will run this workflow against, and the payload that triggered the action. To learn more about this, check out the GitHub docs on Webhook events & payloads. To get the repo URL, create a function called getRepoUrl which accepts the git Context. This destructures the properties repo and serverUrl, and the function will return the remote URL of the repository. GitHub Diff Using the GitHub API, we can access the diff between the current head, and the target branch which a pull request is referencing. The dependency already installed comes with an OctoKit module. We also need the GitHub token for this to properly work. Go back to the src/index.ts file, and modify it to look like the file below. ` Let's walk through the getDiff function. First, check to see if you have the GitHub token, and that the context payload exists. Then, declare and assign the octokit for GitHub REST API access. Then, call the compareCommits method, and pass the properties from the GitHub context. Then, return result files or an empty array. If you do not have either, the token or a pull request will return an empty array. Modify the action.yml file to look like this in order to access the GitHub token: ` Finally, modify .github/workflow/test.yml to pass the GitHub token: ` Now, commit the code and push to a remote repository to test the final result. Conclusion GitHub Actions are powerful tools for implementing CI/CD in your projects no matter the size, and can be used for testing code before deployment and staging. If you need further support, I encourage you to watch Chris' training, Creating Your Own GitHub Action with TypeScript to follow along with him!...
Jun 6, 2022
6 mins
Announcing Free JavaScript Training During the JavaScript Marathon - This Dot Celebrates Remote Corporate Training Courses with Free Classes All April
While we are all stuck at home and our Netflix queues are running out, we at This Dot are announcing free JavaScript courses for the month of April. The Javascript Marathon goes live every Wednesday with a full schedule of Angular, React, Vue, RxJS, and Web Performance courses as a celebration to the release of our new remote corporate training program. The series of free courses are a once-weekly day full of live training sessions on some of the leading web development technologies, and concepts! Starting Wednesday, April 1st, This Dot will host hour-long sessions, beginning at 12:30PM EDT, on React, Angular, Vue, Web Performance, and RxJS. Stay for one training, or stick around for the whole day! No two sessions will be the same! - April 1, 2020: 1 Hour to Learn React - April 8, 2020: An Introduction to Gatsby with React - April 15, 2020: An Introduction to Netflify with React - April 22, 2020: Using GraphQL with React - April 1, 2020: 1 Hour to Learn Angular - April 8, 2020: The Best Pro Tips for A11Y in Angular - April 15, 2020: Master PWA in Angular - April, 22, 2020: Advanced NgRx: Complex Angular State Management - April 29, 2020: Easy Angular Unit Testing in NgRx - May 6, 2020: A Guide to Advanced Angular Patterns (Route Guards, Pipes, Interceptors, and more) - April 1, 2020: 1 Hour to Learn Vue - April 8, 2020: Master State Management in Vue with VueX - April 15, 2020: Master PWA in Vue - April 22, 2020: Learning Unit Testing in Vue - April 29, 2020: Pro Tips on Using AWS with Vue - May 6, 2020: Debugging Vue: Quick Tips and Tricks - April 1, 2020: Web Performance: Basics - April 8, 2020: Web Performance: Budgeting for the Critical Rendering Path - April 15, 2020: Web Performance: Rendering faster with a shade of PRPL - April 22, 2020: Web Performance: Tracing with DevTools - April 29, 2020: Web Performance: Always Auditing with Lighthouse - May 6, 2020: Web Performance: Maintaining web performance in the long term - April 1, 2020: 1 Hour to Learn RxJS - April 15, 2020: Flattening Operators 101 - April 29, 2020: Subjects 101 More trainings are yet to be announced! Need private trainings for your company? If you would like to learn more about how you can leverage This Dot’s expertise to upskill your team, and reinvigorate your developers with new knowledge about the web’s leading development technologies, visit the trainings page....
Mar 25, 2020
4 mins