npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@hauslo/pipeline

v0.1.3

Published

Heavily opinionated automated test, build and deploy pipelines. Makes prod-faring development a joy.

Downloads

10

Readme

pipeline

Heavily opinionated automated test, build and deploy pipelines.

Makes prod-faring development a joy.

Opinionated

  • Monorepo
  • Gitlab
  • Gitlab CI/CD
  • AWS
  • AWS S3, EC2 (IAM, Scaling Groups, VPCs, ...)
  • Terraform
  • Docker

ToC

How to use

Prerequisites

Install the package at the root of a repo/monorepo

npm install @hauslo/pipeline

Generate a .pipeline.yml configuration file

npx @hauslo/pipeline init

Add a resource to .pipeline.yml

version: x.x.x
namespace: xxxxxx
resources:
  demo:
    module: @hauslo/pipeline-website-static
    src: website/demo
    options: {}

Install the modules as required

npm install @hauslo/pipeline-website-static

Create a simple websites/demo/public/index.html file

Now just commit and push to master

git add .
git commit -m "Test pipeline"
git push

And that's it, if your Gitlab CI was configured with AWS credentials the static website in websites/demo/public will have been deployed to S3 from the ci/cd pipeline.


Modules

Infrastructure modules


Todo and ideas


Write a module

Modules are npm packages, they must be installed in the repository alongside @hauslo/pipeline.

A module must export an async function that will receive a single object as argument, the signature of this object is

version: string
namespace: string
module: string
name: string
paths: object<string>
options: object<*>|undefined
id: string
domain: string
slug: string

Where

  • version is the version of @hauslo/pipeline, the argument object signature depends on this value. A module can ignore this argument if it exports .versionCompatibility (ex: 1.0.0 implies ^1.0.0, semver.satisfies() is used)
  • namespace is a project namespace (ex: test/demo, any character is acceptable but the namespace will be trimmed down as necessary when namespacing resources)
  • module is the module name given in .pipeline.yml (ex: @hauslo/pipeline-website-static)
  • name is the resource name, as defined in .pipeline.yml
  • paths helps modules to navigate the project repository. These paths are expected to be used to build the pipeline.
  • options is the module options object found in .pipeline.yml. It may contain values to configure the module's behavior. If the module exposes a validate(options: *) method then it is used to validate the user options
  • id is the resource unique identifier, it includes the project namespace, the pipeline module name, and the resource name. This id, and the next domain and slug, should be used to name the built ci/cd pipeline and infrastructure (ex: app__hauslo_website_static__demo)
  • domain is the same as id but is more suited to name some infrastructure resources (ex: demo.hauslo-website-static.app)
  • slug is the same as id but is more suited to name some infrastructure resources (ex: demo-hauslo-website-static-app)

An example of paths :

{
 "repo": ".",
 "src": "front/demo",
 "_src": "../..",
 "build": ".pipeline",
 "_build": "..",
 "res": "front/demo",
 "_res": "../.."
}

Where

  • repo is the path to the root of the repository from the execution context (the execution context for the pipeline build command, not for .gitlab-ci.yml or terraform, for .gitlab-ci.yml the execution context is the repo root, for terraform the execution context is build so the repo path is _build)
  • src is the path to the resource subrepo from repo (ex: websites/demo/)
  • build is the path to the pipeline build root from repo (ex: .pipeline/)
  • res is the path to the resource-specific build from the pipeline build root (ex: website-static/demo/ for .pipeline/website-static/demo)

And

  • _<path> is the reverse of <path> for src, build and res

Modules can place shared build artifacts in build (terraform configuration files for instance as this is the terraform execution context) and private build artifacts in build/res

The async function exported by the module can return an object

gitlabCiInclude: string|array<string>

Where

  • gitlabCiInclude is the path to a .gitlab-ci.yml file to include from the main .gitlab-ci.yml

Namespacing

For sanity, infrastructure resources should be named after id, domain or slug.

Versionning

To ensure that a module is only ever used with a compatible version of pipeline, it can export a versionCompatibility property with a semver version number (ex: module.exports.versionCompatibility = "1.0.0";)

Terraform

Modules can place shared build artifacts in build (terraform configuration files for instance as this is the terraform execution context) and private build artifacts in build/res.

Modules terraform configurations can declare the variables ci_registry, ci_registry_user and ci_registry_password, these variables will be passed as environment variables from .gitlab-ci.yml.

Modules should document other secrets they require and users should define these secrets in Gitlab CI environment variables (ex: AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY).

variable "ci_registry" {
  type        = string
}
variable "ci_registry_user" {
  type        = string
}
variable "ci_registry_password" {
  type        = string
}