DEV Community: Dak Washbrook

Conveniently link users to a pre-filled New GitHub Personal Access Token Page

Dak Washbrook — Sun, 15 Nov 2020 06:29:41 +0000

My use case was allowing users to update a CLI tool directly from a private repo's releases that they would already have access to. The CLI tool required a valid GitHub access token with specific permissions.

To make this easy for the users, I wanted the CLI tool to open up directly into a pre-filled permissions page, instead of having to fill it in based on a README.md entry.

I dug around the page for the id of the input fields to see if I could use those to pre-fill. After trying a few variations I found it!

The base URL is

https://github.com/settings/tokens/new

Appending the following query parameters onto the URL allows us to pre-fill the form.

For Example:

https://github.com/settings/tokens/new?description=my-cli-tool&scopes=repo,read:packages,read:org

description fills the "Note" field.
scopes allows for a comma-separated list of the scopes.

Now your user only needs to press "Generate token" at the bottom of the page.

Install NGINX Ingress Controller on Kubernetes + Let's Encrypt Cert Issuer

Dak Washbrook — Sat, 14 Nov 2020 20:43:39 +0000

This article is a perspective rewrite of the given sources that allowed me to get from point A to point B from my perspective.

Requirements:

A Kubernetes Cluster
Helm (https://helm.sh/docs/using_helm/)

I recommend DigitalOcean for a very affordable Kubernetes Cluster.

Click here to sign-up for Digital Ocean: https://m.do.co/c/79bf9fee3de8.

Amazon has its own Managed k8s service as well: https://aws.amazon.com/eks/.

Google (the creators of Kubernetes) has its own, very convenient and highly managed, k8s service. https://cloud.google.com/kubernetes-engine/.

Apply the latest version of the NGINX Ingress Controller

Check https://github.com/kubernetes/ingress-nginx/releases for the newest version number.

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/mandatory.yaml

Output:

namespace/ingress-nginx created
configmap/nginx-configuration created
configmap/tcp-services created
configmap/udp-services created
serviceaccount/nginx-ingress-serviceaccount created
clusterrole.rbac.authorization.k8s.io/nginx-ingress-clusterrole created
role.rbac.authorization.k8s.io/nginx-ingress-role created
rolebinding.rbac.authorization.k8s.io/nginx-ingress-role-nisa-binding created
clusterrolebinding.rbac.authorization.k8s.io/nginx-ingress-clusterrole-nisa-binding created
deployment.extensions/nginx-ingress-controller created

Install the Cloud Generic Load Balancer for the Ingress

$ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/nginx-0.24.1/deploy/provider/cloud-generic.yaml -n ingress-nginx

Output:

service/ingress-nginx created
// If you want all nodes to pass the health check:
$ kubectl patch svc ingress-nginx -n ingress-nginx -p '{"spec":{"externalTrafficPolicy":"Cluster"}}'

You can check on the service with:

$ kubectl get svc --namespace=ingress-nginx

Installing cert-manager + lets-encrypt

Apply the CRDs (Custom Resource Definitions)

$ kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/release-0.8/deploy/manifests/00-crds.yaml

Output:

customresourcedefinition.apiextensions.k8s.io/certificates.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/challenges.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/clusterissuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/issuers.certmanager.k8s.io created
customresourcedefinition.apiextensions.k8s.io/orders.certmanager.k8s.io created

Set a label on kube-system namespace to enable advanced resource validation with a webhook.

$ kubectl label namespace kube-system certmanager.k8s.io/disable-validation="true"

Output:

namespace/kube-system labeled

If you do not have Helm installed on your client and k8s cluster. Before the next step, I had to install the Helm client (https://helm.sh/docs/using_helm/) and run the following command:

$ helm init

Output:

$HELM_HOME has been configured at /Users/<User>/.helm.
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation

Then I had to give tiller a ServiceAccount and link everything up via roles.

$ kubectl create serviceaccount --namespace kube-system tiller

Output:

serviceaccount/tiller created
$ kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller

Output:

clusterrolebinding.rbac.authorization.k8s.io/tiller-cluster-rule created
$ kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'

Output:

deployment.extensions/tiller-deploy patched

Add jetstack to your Helm repositories.

$ helm repo add jetstack https://charts.jetstack.io

Output:

"jetstack" has been added to your repositories

Install the cert-manager helm chart.

$ helm install --name cert-manager --namespace kube-system jetstack/cert-manager --version v0.8.0

Output:

NAME:   cert-manager
LAST DEPLOYED: Tue Jun 25 08:39:05 2019
NAMESPACE: kube-system
STATUS: DEPLOYED
RESOURCES:
==> v1/ClusterRole
NAME                                    AGE
cert-manager-edit                       3s
cert-manager-view                       3s
cert-manager-webhook:webhook-requester  3s
==> v1/Pod(related)
NAME                                     READY  STATUS             RESTARTS  AGE
cert-manager-5d669ffbd8-glqgv            0/1    ContainerCreating  0         3s
cert-manager-cainjector-79b7fc64f-bwn7t  0/1    ContainerCreating  0         3s
cert-manager-webhook-6484955794-p2jgn    0/1    ContainerCreating  0         3s
==> v1/Service
NAME                  TYPE       CLUSTER-IP      EXTERNAL-IP  PORT(S)  AGE
cert-manager-webhook  ClusterIP  ${CLUSTER_IP}  <none>       443/TCP  3s
==> v1/ServiceAccount
NAME                     SECRETS  AGE
cert-manager             1        3s
cert-manager-cainjector  1        3s
cert-manager-webhook     1        3s
==> v1alpha1/Certificate
NAME                              AGE
cert-manager-webhook-ca           3s
cert-manager-webhook-webhook-tls  2s
==> v1alpha1/Issuer
NAME                           AGE
cert-manager-webhook-ca        2s
cert-manager-webhook-selfsign  2s
==> v1beta1/APIService
NAME                                  AGE
v1beta1.admission.certmanager.k8s.io  3s
==> v1beta1/ClusterRole
NAME                     AGE
cert-manager             3s
cert-manager-cainjector  3s
==> v1beta1/ClusterRoleBinding
NAME                                 AGE
cert-manager                         3s
cert-manager-cainjector              3s
cert-manager-webhook:auth-delegator  3s
==> v1beta1/Deployment
NAME                     READY  UP-TO-DATE  AVAILABLE  AGE
cert-manager             0/1    1           0          3s
cert-manager-cainjector  0/1    1           0          3s
cert-manager-webhook     0/1    1           0          3s
==> v1beta1/RoleBinding
NAME                                                AGE
cert-manager-webhook:webhook-authentication-reader  3s
==> v1beta1/ValidatingWebhookConfiguration
NAME                  AGE
cert-manager-webhook  2s
NOTES:
cert-manager has been deployed successfully!
In order to begin issuing certificates, you will need to set up a ClusterIssuer
or Issuer resource (for example, by creating a 'letsencrypt-staging' issuer).
More information on the different types of issuers and how to configure them
can be found in our documentation:
https://docs.cert-manager.io/en/latest/reference/issuers.html
For information on how to configure cert-manager to automatically provision
Certificates for Ingress resources, take a look at the `ingress-shim`
documentation:
https://docs.cert-manager.io/en/latest/reference/ingress-shim.html

Create a file called issuer.yaml:

apiVersion: certmanager.k8s.io/v1alpha1
kind: ClusterIssuer
metadata:
  name: letsencrypt
spec:
  acme:
    # The ACME server URL
    server: https://acme-v02.api.letsencrypt.org/directory
    # Email address used for ACME registration
    email: ${YOUR_EMAIL_ADDRESS}
    # Name of a secret used to store the ACME account private key
    privateKeySecretRef:
      name: letsencrypt
    # Enable the HTTP-01 challenge provider
    http01: {}

Replace ${YOUR_EMAIL_ADDRESS} with your e-mail address.

Create the issuer with the following command:

$ kubectl create -f issuer.yaml

Output:

clusterissuer.certmanager.k8s.io/letsencrypt created

See this example Ingress resource using the issuer:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: echo-ingress
  annotations:  
    kubernetes.io/ingress.class: nginx
    certmanager.k8s.io/cluster-issuer: letsencrypt
spec:
  tls:
  - hosts:
    - echo1.example.com
    - echo2.example.com
    secretName: letsencrypt
  rules:
  - host: echo1.example.com
    http:
      paths:
      - backend:
          serviceName: echo1
          servicePort: 80
  - host: echo2.example.com
    http:
      paths:
      - backend:
          serviceName: echo2
          servicePort: 80

Create as many Ingress resources as you would like. The best practice, in my opinion, is having 1 per domain, just for organizational reasons.

If you have any questions or comments please feel free to comment below!

Thanks!

Sources:

Delete All Releases from GitHub Repo

Dak Washbrook — Sat, 14 Nov 2020 20:32:47 +0000

I wanted to clean out the releases I had in a GitHub repo. Googled around and ended up using this command since i already had the GitHub CLI installed.

If you do not already have the GitHub CLI installed, check out the repo (https://github.com/cli/cli) for instructions.

The command:

$ gh release list | sed 's/|/ /' | awk '{print $1, $8}' | while read -r line; do gh release delete -y "$line"; done

gh release list gets a list of releases as a table.

sed 's/|/ /' | awk '{print $1, $8}' singles out the first column provided by the table.

while read -r line; do gh release delete -y "$line"; done ran the delete command for each result.

Result:

✓ Deleted release darwin-75c5ae281acc12eb95445162d0bc0f73dcc51ace
✓ Deleted release darwin-8d25e0f94558b753f8d58509ca03cbe6e0c86cab
✓ Deleted release darwin-e0a28dd3b2df98f48e30fd851a4e1ef9990ed7b3
✓ Deleted release darwin-3f3aa570acd185016cb11d5aecc61749fd907d6f
✓ Deleted release darwin-37c8382ef2e1e170642f24d45a31c5c3e9004084
✓ Deleted release darwin-d41e9be524b62be4b30ea7786592851f949dda5d
✓ Deleted release darwin-b57896ec7121e59c32e5f62e39bee5cb1edd42be
✓ Deleted release darwin-7849de58c872a2decf43e520ec42b804f41d85f3
✓ Deleted release darwin-07df533961c2d8cfd34245672f7d9ff16f6bb8e6
✓ Deleted release darwin-870a61ff358d7bbc5d97b290ffd32be1501bbddb
✓ Deleted release darwin-21de7c7db92d4d5add9f7539f2ba2993f2d41cd2
✓ Deleted release linux-master
✓ Deleted release linux-21de7c7db92d4d5add9f7539f2ba2993f2d41cd2
✓ Deleted release windows-21de7c7db92d4d5add9f7539f2ba2993f2d41cd2
✓ Deleted release linux-12542d8ae15ac6c3a28a3bb8da7ae297bb0e69a0
✓ Deleted release windows-12542d8ae15ac6c3a28a3bb8da7ae297bb0e69a0
✓ Deleted release linux-99ce7f2f6eaae14dfb5d491888115b1fd71d998a
✓ Deleted release windows-99ce7f2f6eaae14dfb5d491888115b1fd71d998a
✓ Deleted release windows-3acd65caf2f6ea063feba12861eea021fe9f506e
✓ Deleted release linux-a2054c7f47352884edcdbd4777f66b416563b980
✓ Deleted release windows-a2054c7f47352884edcdbd4777f66b416563b980
✓ Deleted release linux-65103ccc3b98cfcf553220bc193e2383e6047169
✓ Deleted release windows-65103ccc3b98cfcf553220bc193e2383e6047169
✓ Deleted release windows-1f435af0cfaa7bd2d4f026b34ceaeaf671eb0a51
✓ Deleted release linux-ca6f22638afc0985245a95ad799fe6b0a38a6477
✓ Deleted release windows-ca6f22638afc0985245a95ad799fe6b0a38a6477
✓ Deleted release windows-d59c68d12992765781c8803c79213cbae6e6155b

After deleting all of the releases I had to also get rid of all the tags. This command did that for me.

$ git fetch
$ git tag -l | xargs -n 1 git push --delete origin

Extend Express Request in TypeScript

Dak Washbrook — Fri, 06 Nov 2020 06:49:32 +0000

Utilizing the functionality of TypeScript to extend the Request type in Express allowing us to pass our own types to be used with the Request object.

In the example below, I wanted to be able to add a services key to the Express Request object and pass interfaces for Query, Params and Body.

I also reordered some of the types in order of what I most frequently used, making everything optional.

// types.ts
import * as core from 'express-serve-static-core'
import {
  ReportService,
} from './services'

interface IRequestServices {
  ReportService: () => ReportService,
}

export interface Query extends core.Query { }

export interface Params extends core.ParamsDictionary { }

export interface Request<ReqBody = any, ReqQuery = Query, URLParams extends Params = core.ParamsDictionary>
  extends express.Request<URLParams, any, ReqBody, ReqQuery> {
    services: IRequestServices,
  }

// controller.ts
import express from 'express'
import { Params, Query, Request } from '../../types'

interface RequestBody {
  name: string
}

interface RequestQuery extends Query {
  category: string
}

interface RequestParams extends Params {
  reportId: string
}

const updateNameController = async (req: Request<RequestBody, RequestQuery, RequestParams>, res: express.Response): Promise<void> => {
  const reportService = req.services.ReportService()
  const report = await reportService.updateReportName(req.params.reportId, req.query.category, req.body.name)
  return res.status(200)
}

export default updateNameController

Let me know your thoughts in the comments!

Catch ExpressJS Async Errors

Dak Washbrook — Fri, 06 Nov 2020 06:15:16 +0000

If you tried or happened to throw an error from within an async express route handler then you are probably looking at an error that looks like this:

UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with.catch(). (rejection id: 1)

[DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Trying to find the cleanest solution to this has led me to quite a few places that offer the following solutions:

Wrapping all request handler logic in try/catch blocks to pass the caught error to the next() function
Wrapping every request handler inside a function that checks if the handler is an async function to further wrap it with a .catch(next).

You can see both of these explained here: https://zellwk.com/blog/async-await-express/. These are both viable solutions. Though, I wanted to seek out a way to do this passively instead of actively.

This is what led me to utilize JavaScript's native Proxy built-in:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy)

Used in tandem with the handler.apply() method, explained here:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy/Proxy/apply.

Below is a singular simple patch to fix this issue, without having to do anything with each async request handler.

const Layer = require('express/lib/router/layer')

Object.defineProperty(Layer.prototype, 'handle', {
  set: function (handle) {
    this._handle = new Proxy(handle, {
      apply: function (target, thisArg, argumentsList) {
        const type = target.constructor.name
        if (type === 'AsyncFunction') {
          const wrappedFunction = (...args) => {
            const next = args[args.length - 1] || Function.prototype
            target.apply(thisArg, args).catch(next)
          }
          wrappedFunction(...argumentsList)
          return
        }
        target.apply(thisArg, argumentsList)
        return
      }
    })
  },
  get: function () {
    return this._handle
  }
})

Import or run this piece of code upon server startup and it will patch express.

There is a very similar version of this here https://github.com/davidbanham/express-async-errors/blob/master/index.js as well.

Let me know your thoughts in the comments below!