Writing Your First GitHub Actions with Typescript

Writing Your First GitHub Actions with Typescript

I think I'll build an action that will deploy my database schema ... Looking a little closer, it seems that everything is written using TypeScript.

GitHub Actions is a CI/CD platform

GitHub Actions (as for other CI/CD services/platforms):

  • Triggers on events
  • Prepare environment(s)
  • Runs workflow(s)
  • Report results

A GitHub Action can either be a Dockerfile or Javascript

In a Dockerfile action:

  • The environment is defined by container layers
  • The workflow is defined by entry point bash script

In a JavaScript action:

  • The environment is defined in the [package.json](https://docs.npmjs.com/files/package.json), as NPM modules
  • The workflow is defined by the JavaScript/TypeScript code

JavaScript actions are faster and more stable

The strength of JavaScript actions, compared with Dockerfile actions, are:

  • The familiar syntax for most web/mobile/back end developers
  • Runs everywhere (JavaScript is less restrictive than Docker)
  • Runs faster by skipping container building and VM warm-ups.

Note: Let’s treat ourselves better and use TypeScript instead of JavaScript!

Step 1: Configure the Action

The configuration will let GitHub know how to run the action and how to list it on the GitHub marketplace.

The configuration is defined with a yaml file, action.yml, that contains:

  • The name of the action
  • The arguments to the action
  • The entry point to run the action

credit: example GitHub Actions configuration from readable-readme

Step 2: Implement the Microservices
  1. write source code for your magical action:

  1. Compile into JavaScript code and add them to source control.

  1. Point action entry point to the compiled JavaScript code.

Step 3: Publish the Action

Publishing your action means making a release in your repository!

  1. Give it a version number (semantic versioning preferred.)

  2. Leave a short release description.

  1. Release and get a cup of coffee.

Step 4: Start Using the Action
  1. Add the released action to the workflow.

  1. watch the result and get another cup of coffee!

  1. This action lints documentation and generate reports:

Thank you for reading!

Understanding of GitHub and Actions to Improve Your Workflow

Understanding of GitHub and Actions to Improve Your Workflow

If you host your code on GitHub, you can take advantage of GitHub Actions. Instead of running all tests and linters manually, you can leverage GitHub Actions for those tasks. Learn more Github Actions in this post, improve Your Workflow With These 4 GitHub Actions

Github Actions - What, Why, and How?

Automate boring tasks with Github Actions

GitHub Actions make it easy to automate all your software workflows. Github Actions let you build, test, and deploy your code right from GitHub. You can also assign code reviews, manage branches, and triage issues the way you want with actions.

Whether you want to build a container, deploy a web service, or automate welcoming a new user to your open-source project — there’s an automated action for that.

The easiest way is to think of Github Actions as their own continuous integration system. You can pair GitHub Packages with Actions to simplify package management, including version updates, fast distribution with the Github global CDN, and dependency resolution, using your existing GITHUB_TOKEN.

Getting Started

Every Github repository now supports Github's actions. Open a repository in the browser, and you’ll spot the “Actions” tab right away.

Source: Github

Once we press on the Actions tab, we’ll be taken to the Actions page.

Actions tabs

Github is smart enough to recommend relevant actions. Let’s say we have a Node project where we want to test whether the build command works before shipping our code to the production server. Press on the “set up on this workflow” button.

nodejs.yml

Every Github action required a .yml file. The .yml file is used to describe actions, behavior, and everything else.

.yml stands for YAML (“YAML Ain’t Markup Language”), which is a human-readable data serialization language. It’s commonly used for configuration files and in applications where data is being stored or transmitted.

Before committing the freshly created nodejs.yml file, Github gives us a chance to glance over it. Everything seems in order, and here’s what’s happening inside the file:

  • Spin up a Ubuntu server
  • Install Node.js
  • Install node packages for the project
  • Fire off the package.json scripts like npm run build and npm run test

Alrighty, let’s commit the file to the project now.

Committing the nodejs.yml file

Now every time you push to the project, the commands will fire off automatically. There’s even action for deploying to AWS or Google Cloud.

Checks running on each push

Github actions aren’t just for the Web or Node exclusively — they’re also for languages and environments. Explore all the actions here.

The best part about actions is you can write your own action and open-source it for the whole world to see.

Improve Your Workflow With These 4 GitHub Actions

Here are 4 useful GitHub Actions to improve your workflow

1. Detect Secret Key Leaks — gitleaks-action

Audit Git commits for secrets with gitleaks, as a GitHub action. If you use .env files, this action notifies you if you ever published the secrets by accident.

Gitleaks-action — https://github.com/eshork/gitleaks-action

Usage

workflow "gitleaks my commits" {
  on = "push"
  resolves = ["gitleaks"]
}
action "gitleaks" {
  uses = "eshork/[email protected]"
}

Credit to zricethezav/gitleaks for the complicated bits.

2. Audit Your Webpage With Google Chrome’s Lighthouse Test

This action integrates Google’s helpful Lighthouse audits for webpages — specifically testing for performance, accessibility, best practices, SEO, and progressive web apps.

*Github Lighthouse Action — https://github.com/marketplace/actions/lighthouse-audit

Right now, the action will print the five scores (out of 100) to the output and upload HTML and JSON versions of the report as artifacts.

In the next release, the action will let you specify thresholds for each test and optionally fail this step if they are not met.

Lighthouse audit report example

Usage

The following workflow runs a Lighthouse audit on jarv.is, shows the five scores in the output of the step, and uploads the .html and .json results as artifacts to download (as shown above).

workflow.yml file:

name: Audit live site
on: push
jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
    - name: Audit live URL
      uses: jakejarvis/[email protected]
      with:
        url: 'https://jarv.is/'
    - name: Upload results as an artifact
      uses: actions/[email protected]
      with:
        name: report
        path: './report'

Lighthouse is super useful when you’re building progressive web apps. The project is inspired by GoogleChromeLabs/lighthousebot.

3. Run SSH Commands With GitHub Actions

This action will run the provided argument as a command on your $HOST via SSH. Useful if you want to run commands on your private server after each commit or push.

SSH GitHub Action — https://github.com/maddox/actions/tree/master/ssh

Usage

To use the action, simply add the following lines to your .github/main.workflow:

action "Run deploy script" {
  uses = "maddox/actions/[email protected]"
  args = "/opt/deploy/run"
  secrets = [
    "PRIVATE_KEY",
    "HOST",
    "USER"
  ]
}

Required arguments

The argument you will use is the command that will be run on your server via SSH.

Examples

  • args = "/opt/deploy/run"
  • args = "touch ~/.reload"

Required secrets

You’ll need to provide some secrets to use the Action.

  • PRIVATE_KEY: Your SSH private key.
  • HOST: The host the action will SSH to run the command. For example, your.site.com.
  • USER: The user the SSH command will auth as with the private key.

Please see the GitHub repository for full details.

4. GitHub Action That Runs ESLint

Eslint Action — https://github.com/stefanoeb/eslint-action

This action executes the ESLint linter on specified JavaScript files without any previous action/build step or Docker required.

You must have the ESLint running locally for the Action to execute. It will use the same rules as you do locally. More info in the ESLint getting started guide

Usage

Add any of the examples below to your workflow file .github/main.workflow.

Here’s an example to get it to work:

workflow "New workflow" {
  on = "push"
  resolves = ["ESLint"]
}
action "ESLint" {
  uses = "stefanoeb/[email protected]"
}

By default, it will run ESLint through all the files in the project. But you can also specify a glob of files on the args, just like ESLint:

workflow "New workflow" {
  on = "push"
  resolves = ["ESLint"]
}
action "ESLint" {
  uses = "stefanoeb/[email protected]"
  args = "index.js src/**.js"
}

If there is no previous step installing the necessary modules, this action will execute a yarn install or npm install automatically.

You may also like: GitHub Development Workflow - Developers need to know.

Conclusion

Thanks for reading, I hope you learned something new. If you know any useful GitHub Actions, let us know. Stay curious and happy coding!

What TypeScript taught me about JavaScript

What TypeScript taught me about JavaScript

What TypeScript taught me about JavaScript. TypeScript was designed to make the most sense out of any JavaScript code. How void behaves in both TypeScript and JavaScript. What Symbols are and why they can be unique. Why substitutability is such an important concept for TypeScript

TypeScript was designed to make the most sense out of any JavaScript code. Given the dynamic nature of JavaScript, this can lead to some very interesting typings that may seem odd at a first glance. In this talk, we will look at JavaScript scenarios that are easy to understand, but complex to define. We then see what tools TypeScript provides to make the most dynamical behaviour predictable, in the most elegant way possible.

Join us and learn:

  • How void behaves in both TypeScript and JavaScript
  • What Symbols are and why they can be unique
  • The constructor interface pattern, and why classes are more complex than you might think
  • Why substitutability is such an important concept for TypeScript
    ... and much more!

Introduction Boolean in JavaScript and TypeScript

Introduction Boolean in JavaScript and TypeScript

Boolean values are supported by both JavaScript and TypeScript and stored as true/false values .This is because, while JavaScript coerces an object to its primitive type, the TypeScript type system does not. TypeScript treats it like an object type.

Boolean in JavaScript

boolean can take the values of true and false. Values from other types can be truthy or falsy, like undefined or null.

let b = true
if(b) console.log('logged')

b = false
if(b) console.log('not logged')

b = undefined
if(b) console.log('not logged')

b = null
if(b) console.log('not logged')

Values other than undefined, null or false considered falsy are "" (empty string), -0 and 0, as well as NaN.

To get the boolean value of any value, you can use the Boolean function:

Boolean(false) // false
Boolean(true) // true
Boolean("false") // true ❗️
Boolean("Hey folks") // true
Boolean({}) // true
Boolean([]) // true
Boolean(123.4) // true
Boolean(Symbol()) // true
Boolean(function() {}) // true
Boolean(undefined) // false
Boolean(null) // false
Boolean(NaN) // false
Boolean(0) // false
Boolean("") // false

Rule of thumb: All empty values evaluate to false. Empty object {} and empty array [] (which is an object itself) do have value as they are containers for other values.

The Boolean function is really good to filter empty values from collections:

const collection = [
  { name: 'Stefan Baumgartner', age: 37 },
  undefined,
  { name: 'D.', age: 36 },
  false
  { name: 'C.', age: 2},
  false
]

collection.filter(Boolean) // handy!

Together with Number – which converts all values into their number counterpart or NaN, this is a really cool way of getting to actual values quickly:

const x = ["1.23", 2137123, "wut", false, "lol", undefined, null]
  .map(Number)
  .filter(Boolean) // [1.23, 2137123] 👍

Boolean exists as a constructor and has the same conversion rules as the Boolean function. However, with new Boolean(...) you create a wrapping object, making value comparisions truthy, but reference comparisions falsy:

const value = Boolean("Stefan") // true
const reference = new Boolean("Stefan") // [Boolean: true]

value == reference // true
value === reference // false

You get to the value via .valueOf():

value === reference.valueOf() // true

I have a REPL for you to check. The use of Boolean as a function is obviously great, but new Boolean has very limited use. If you know a practical use case, please let me know.

Boolean in TypeScript

boolean in TypeScript is a primitive type. Be sure to use the lower case version and don’t refer to
object instances from Boolean

const boolLiteral: boolean = false // 👍
const boolObject: Boolean = false // 👎

It works, but it’s bad practice as we really rarely need new Boolean objects.

You can assign true, false and undefined and null to boolean in TypeScript without strict null checks.

const boolTrue: boolean = true // 👍
const boolFalse: boolean = false // 👍
const boolUndefined: boolean = undefined // 👍
const boolNull: boolean = null // 👍

With that, boolean is the only one we can express fully through union types:

type MyBoolean = true | false | null | undefined // same as boolean

const mybool: MyBoolean = true
const yourbool: boolean = false

When we enable the strictNullChecks compiler flag, the set of values reduces to true and false.

const boolTrue: boolean = true // 👍
const boolFalse: boolean = false // 👍
const boolUndefined: boolean = undefined // 💥
const boolNull: boolean = null // 💥

So our set reduces to two values in total.

type MyStrictBoolean = true | false

We can also get rid of null values with the NonNullable helper type:

type NonNullable<T> = T extends null | undefined
  ? never
  : T;

type MyStrictBoolean = NonNullable<MyBoolean> // true | false

The fact that boolean consists of a limited set of values only used in conditions, allows for interesting conditional types.

Think of an mutation in a datastore through a function. You set a flag in a function that updates e.g. the user id. You have to provide the user ID then:

type CheckUserId<Properties, AddUserId> = 
    AddUserId extends true 
    ? Properties & { userId: string }
    : Properties & { userId?: string }

Depending on the value of our generic AddUserId, we expect the property userId to be set or to be optional.

We can make this type more explicit by extending our generics from the types we expect

- type CheckUserId<Properties, AddUserId> = 
+ type CheckuserId<
+  Properties extends {},
+  AddUserId extends boolean
+ >
     AddUserId extends true 
     ? Properties & { userId: string }
     : Properties & { userId?: string }

In use, it might declare a function like this:

declare function mutate<P, A extends boolean = false>
  (props: CheckUserId<P, A>, addUserId?: A): void

Note that I even set a default value for A to make sure CheckUserId gives the correct info depending on addUserId to be set or not.

The function in action:

mutate({}) // 👍
mutate({ data: 'Hello folks' }) // 👍
mutate({ name: 'Stefan' }, false) // 👍
mutate({ name: 'Stefan' }, true) // 💥 userId is missing
mutate({ name: 'Stefan', userId: 'asdf' }, true) // 👍 userId is here

Handy if your code relies a lot on truthy and falsy values. As always, there’s playground for you.

Originally published at fettblog.eu on 10 September 2019