Continuous integration and delivery tips - gregswindle/eslint-plugin-crc GitHub Wiki

The scripts property of a package.json provides many useful commands for automating build, test, and deploy tasks. This repository uses the following scripts to automate test and build tasks.

✅ All scripts are optional, but recommended. You don't have to use any of these scripts. Omitting one or all will do no harm (but it won't help much, either).

✅ Task-runners are not required. You can execute these tasks without additional task-running frameworks like grunt or gulp.

ℹ️ Reference the article npm-scripts: How npm handles the "scripts" field for more information.

The npm test command runs these scripts in the following order:

1. pretest runs before any specs are executed
2. test executes your specs
3. posttest executes follow-up tasks, e.g., nsp

The npm version command runs these scripts in the following order:

1. preversion
2. version
3. postversion

eslint-plugin-crc uses [semantic-release] and several plugins to automate semver bumps, CHANGELOG updates, GitHub releases, and npm registration:

    "@semantic-release/changelog": "1.0.1",
    "@semantic-release/git": "3.0.1",
    "@semantic-release/npm": "3.0.2",
    "semantic-release": "^12.4.1",

The npm-script release coordinates:

"release": {
    "verifyConditions": [
      "@semantic-release/changelog",
      "@semantic-release/npm",
      "@semantic-release/git",
      "@semantic-release/github"
    ],
    "publish": [
      "@semantic-release/changelog",
      "@semantic-release/npm",
      "@semantic-release/git",
      "@semantic-release/github"
    ]
  }

Finally, TravisCI executes semantic-release after any successful merge into master:

jobs:
  include:
    - stage: release
      deploy:
        provider: npm
        skip_cleanup: true
        script:
          - npx travis-deploy-once "npx semantic-release"

You can use the git tag command to put a permanent marker on a specific commit. Later, you can use the tag to compare the tagged commit to other, future commits in the future. When you push to your remote repository, the tag goes along.

For example, if you have created a tag called v0.1.4 in a Git repository you would remove it from your repository by executing the following two commands:

$ git tag -d v0.1.4
$ git push origin :refs/tags/v0.1.4

First, create NEW as an alias of OLD:

$ tag NEW OLD

Then, delete OLD:

$ tag -d OLD

"How do you rename a git tag?"

When you're finished with a branch -- i.e., there has been a merged pull request -- you should delete your working branch.

In most cases, the first clone or fork of a git repos creates a remote with the alias origin. Sometimes our Verizon colleagues won't have access to GitHub.com, however. In those cases, we can create another remote and point it to Verizon's internal Bitbucket repositories.

✅ Standard naming conventions for Verizon remotes If origin isn't pointing at an internal Verizon repos, keep it simple, and use vz as your alternate remote alias. BTW, there is no standard naming convention for this scenario, yet. 😐

$ git remote add vz <remote-uri>
# Verify the new remote
$ git remote -v

Adding a Remote

If you want to change origin's repository:

$ git remote set-url origin <new-url>

Changing a remote's URL

$ git branch -d <branch_name>

$ git push origin --delete <branch_name>

Once all features are done, done, and done for MVP 1, I'll bump the project to semantic version 1.0.0 and publish the project on the public npm registery.

💬 nodejs/Release. (2018). GitHub. Retrieved 20 February 2018, from https://github.com/nodejs/Release/blob/master/README.md

Dates are subject to change.

• ¹: The 8.x Maintenance LTS cycle is currently scheduled to expire early on December 31, 2019 to align with the scheduled End-of-Life of OpenSSL-1.0.2.

ℹ️ The wiki page Semantic versioning explains how this project versions its product.