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

shipit-deploy

v5.3.0

Published

Official set of deploy tasks for Shipit.

Downloads

30,245

Readme

shipit-deploy

Build Status version MIT License

Set of deployment tasks for Shipit.

Features:

  • Deploy tag, branch or commit
  • Add additional behaviour using hooks
  • Build your project locally or remotely
  • Easy rollback

Install

npm install shipit-deploy

If you are deploying from Windows, you may want to have a look at the wiki page about usage in Windows.

Usage

Example shipitfile.js

module.exports = shipit => {
  require('shipit-deploy')(shipit)

  shipit.initConfig({
    default: {
      workspace: '/tmp/myapp',
      deployTo: '/var/myapp',
      repositoryUrl: 'https://github.com/user/myapp.git',
      ignores: ['.git', 'node_modules'],
      keepReleases: 2,
      keepWorkspace: false, // should we remove workspace dir after deploy?
      deleteOnRollback: false,
      key: '/path/to/key',
      shallowClone: true,
      deploy: {
        remoteCopy: {
          copyAsDir: false, // Should we copy as the dir (true) or the content of the dir (false)
        },
      },
    },
    staging: {
      servers: '[email protected]',
    },
  })
}

To deploy on staging, you must use the following command :

shipit staging deploy

You can rollback to the previous releases with the command :

shipit staging rollback

Options

workspace

Type: String

Define a path to a directory where Shipit builds it's syncing source.

Beware to not set this path to the root of your repository (unless you are set keepWorkspace: true) as shipit-deploy cleans the directory at the given path after successful deploy.

Here you have the following setup possibilities:

  • if you want to build and deploy from the directory with your repo:
    • set keepWorkspace: true so that your workspace dir won't be removed after deploy
    • optionally set rsyncFrom if you want to sync e.g. only ./build dir
    • set branch so that we can get correct revision hash
  • if you want every time to fetch a fresh repo copy and dun reploy on it:
    • set shallowClone: true — this will speed up repo fetch speed and create a temporary workspace. NOTE: if you decide not to use shallowClone, you should set workspace path manually. If you set shallowClone: true, then the temporary workspace directory will be removed after deploy (unless you set keepWorkspace: true)
    • set repositoryUrl and optionally branch and gitConfig

keepWorkspace

Type: Boolean

If true — we won't remove workspace dir after deploy.

dirToCopy

Type: String Default: same as workspace

Define directory within the workspace which should be deployed.

deployTo

Type: String

Define the remote path where the project will be deployed. A directory releases is automatically created. A symlink current is linked to the current release.

repositoryUrl

Type: String

Git URL of the project repository.

If empty Shipit will try to deploy without pulling the changes.

In edge cases like quick PoC projects without a repository or a living on the edge production patch applying this can be helpful.

branch

Type: String

Tag, branch or commit to deploy.

ignores

Type: Array<String>

An array of paths that match ignored files. These paths are used in the rsync command.

deleteOnRollback

Type: Boolean

Whether or not to delete the old release when rolling back to a previous release.

key

Type: String

Path to SSH key

keepReleases

Type: Number

Number of releases to keep on the remote server.

shallowClone

Type: Boolean

Perform a shallow clone. Default: false.

updateSubmodules

Type: Boolean

Update submodules. Default: false.

gitConfig

type: Object

Custom git configuration settings for the cloned repo.

gitLogFormat

Type: String

Log format to pass to git log. Used to display revision diffs in pending task. Default: %h: %s - %an.

rsyncFrom

Type: String Optional

When deploying from Windows, prepend the workspace path with the drive letter. For example /d/tmp/workspace if your workspace is located in d:\tmp\workspace. By default, it will run rsync from the workspace folder.

copy

Type: String

Parameter to pass to cp to copy the previous release. Non NTFS filesystems support -r. Default: -a

deploy.remoteCopy.copyAsDir

Type: Boolean Optional

If true - We will copy the folder instead of the content of the folder. Default: false.

Variables

Several variables are attached during the deploy and the rollback process:

shipit.config.*

All options described in the config sections are available in the shipit.config object.

shipit.repository

Attached during deploy:fetch task.

You can manipulate the repository using git command, the API is describe in gift.

shipit.releaseDirname

Attached during deploy:update and rollback:init task.

The current release dirname of the project, the format used is "YYYYMMDDHHmmss" (moment format).

shipit.releasesPath

Attached during deploy:init, rollback:init, and pending:log tasks.

The remote releases path.

shipit.releasePath

Attached during deploy:update and rollback:init task.

The complete release path : path.join(shipit.releasesPath, shipit.releaseDirname).

shipit.currentPath

Attached during deploy:init, rollback:init, and pending:log tasks.

The current symlink path : path.join(shipit.config.deployTo, 'current').

Workflow tasks

  • deploy
    • deploy:init
      • Emit event "deploy".
    • deploy:fetch
      • Create workspace.
      • Initialize repository.
      • Add remote.
      • Fetch repository.
      • Checkout commit-ish.
      • Merge remote branch in local branch.
      • Emit event "fetched".
    • deploy:update
      • Create and define release path.
      • Remote copy project.
      • Emit event "updated".
    • deploy:publish
      • Update symlink.
      • Emit event "published".
    • deploy:clean
      • Remove old releases.
      • Emit event "cleaned".
    • deploy:finish
      • Emit event "deployed".
  • rollback
    • rollback:init
      • Define release path.
      • Emit event "rollback".
    • deploy:publish
      • Update symlink.
      • Emit event "published".
    • deploy:clean
      • Remove old releases.
      • Emit event "cleaned".
    • rollback:finish
      • Emit event "rollbacked".
  • pending
    • pending:log
      • Log pending commits (diff between HEAD and currently deployed revision) to console.

License

MIT