auto-versioning-webviews.md

Auto-versioning Webviews

Table of Contents

• Auto-versioning Webviews
  • Why you should want to
  • How does it work
  • How to set it up
    • Quick Install
    • Installation Guide
      • Steps
      • Update Docs
      • Create the pull request
  • How to Test
    • Testing the Linter
      • Testing locally
      • Testing on Travis
    • Using the helper
    • Testing semantic-release
      • Test that it fails when hitting this branch
      • Test that it semi-succeeds on test branch
  • Misc
    • Creating the Travis token

Why you should want to

How does it work

How to set it up

Quick Install

1. yarn add -D @ifit/{conventional-commit,conventional-commit-lint,semantic-release-webview}

   if using husky<1.0: migrate to the @next version (yarn add -D husky@next). Here's the upgrade docs

2. setup config+scripts in package.json

   "scripts": {
     "commit": "npx @ifit/conventional-commit",
     "cm": "yarn commit",
   },
   "commitlint": {
     "extends": [
       "@ifit/conventional-commit-lint"
     ]
   },
   "husky": {
     "hooks": {
       "commit-msg": "commitlint -e $GIT_PARAMS"
     }
   },
   {
     "release": {
       "extends": "@ifit/semantic-release-webview"
     }
   }

3. update config in travis.yml

   script:
     - commitlint-travis # should probably be before your regular linting
   before_deploy:
     - npx semantic-release # @ifit/semantic-release-webview is configured to only run on the `test` branch

4. Go to Installation Guide -> Steps: continue from step 2.

Installation Guide

Steps

1. Install and configure the following packages (check out their ReadMe for details)

   • https://github.com/ifit/conventional-commit
   • https://github.com/ifit/conventional-commit-lint
   • https://github.com/ifit/semantic-release-webview

2. Setup needed Travis tokens

   • create GITHUB_TOKEN (creation instructions or use the one in 1pass + save it
   • go to your repo's Travis settings (e.g. https://travis-ci.com/ifit/phoenix-goal-settings/settings)
   • create environment config for your GITHUB_TOKEN

3. Tag current version of your repo with v#.#.# where #.#.# is the current version BEFORE auto-versioning kicks in

4. How to Test

5. Update Docs

6. Create the pull request

Update Docs

Let the maintainers now about the versioning strategy and the format for commit messages. Here's an example:

### Committing

This repo now makes use of commit linting to have commit messages conform to the [conventional commit standard](https://conventionalcommits.org/). This means that when committing to this repository, the message of the commit must fit the standard or else the commit will not be successful.

The reasons for this are well laid out [here](https://conventionalcommits.org/#why-use-conventional-commits), but we also really like descriptive commit messages to be in our git history. For more information, please follow the links above, or reach out to one of the chapter leads.

![commit message example](https://raw.githubusercontent.com/ifit/phoenix-goal-settings/semantic-release/docs/example-commit.png?token=ABHKifZ7HRsk3GS8upgd1HRzS5Jmlf7Aks5bjSnGwA%3D%3D)

### Versioning

Handled automatically by `semantic-release`, based on the commit messages when merged into `test`. More info on [semantic versioning](https://semver.org/).

That version should then be accessible at [https://wolf-dashboard-webview.ifit-test.com/#.#.#/index.html](https://wolf-dashboard-webview.ifit-test.com/#.#.#/index.html). Merges into master will be deployed with the latest version number from test.

Here's a visual to include for the commit format

Create the pull request

Include:

• How To Test
• Verifications
  • Travis settings has a GITHUB_TOKEN

How to Test

Testing the Linter

Steps

Testing locally

• modify a file
• stage it with git add
• do a normal commit git commit -am "pedro's fake commit"
• watch it burn and crash 🔥

Testing on Travis

• branch off this repo
• remove the commit hooks to lint locally OR do the next steps directly in github
• modify a file
• commit it with an improper message
• wait for the build to fail

Using the helper

Steps

• modify file
• stage it with git add
• try yarn cm
• go through the little CLI
• don't push up the commit

Testing semantic-release

Steps

Test that it fails when hitting this branch

• run npx semantic-release --dry-run
• note failure with message about it not being the test branch

Test that it semi-succeeds on test branch

• move this branch over to local test
• have a valid GITHUB_TOKEN (aka GH_TOKEN) or create one
• run GH_TOKEN=<copied-token> && npx semantic-release --dry-run
• notice success! 🚀
• reset test: git reset --hard origin/test

Misc

Creating the Travis token

• go to Github Personal access tokens

• create a token

  Snapshot of permissions needed