Forem: Aurore T

Publish your npm packages automatically with Auto and Github Action

Aurore T — Thu, 23 Jul 2020 19:40:02 +0000

If you have your own npm package you make updates to regularly and use in multiple projects, publishing can take time and testing new release can be annoying.

Auto is a tool that allows you to streamline your release process, using labels on your Pull request to know what version to publish, following semantic versioning. Oh, and the cherry on the cake, it generates release notes and CHANGELOG automatically too!

My team has been using for months now, and we love it! Getting a newly published version just from merging a Pull Request saved so much time.

What does Auto does?

We use auto command shipit to handle multiple scenarios automatically:

If it's called from the base branch or main branch (like master) ⇒ A new version of the package is released:

This is the basic feature which will get you a new npm package version.

If it's called from a Pull Request in CI ⇒ a canary version is released: A canary release is like a preview of your package once it's published, like a temporary package version. This is very handy to test your work on a project using your repo and have that repo pass it's own CI requirements or provide testing links to testers.
If called from a pre-release branch (like next) ⇒ A pre-release version will be released:

This is great to create a beta version of your next big update and test them on projects which are using your package.

There are more features you check out on their documentation, but this covers most cases you will need.

Setup

Auto has good documentation available here on how to get you started.

Here is what I had to do to be able to run it via GitHub Actions:

Run npm install --save-dev auto
Create .autorc to add the user info to use with git

{
  "author": {
    "name": "FirtName LastName",
    "email": "youremail@gmail.com"
  }
}

There is a lot more you can configure via .autorc, have a look at the doc here.

Create tokens

To run auto, you need an npm token and a GitHub token. GitHub action provides a token automatically via secrets.GITHUB_TOKEN. You will need to create an npm token with read and publish access level and saved it in your repo secrets as NPM_TOKEN.

Create labels

The main thing you will need to do is to create the labels on your repo via the auto command. You will need to this from your project locally.

Follow these instructions to create a GitHub token. You will need to give it repo permissions.
Once you have your token, run GH_TOKEN={YOUR_TOKEN} auto create-labels from the root of your project.
Once done, you can delete the GitHub token if you have no use for it.

GitHub Action setup

Create a new workflow file .github/workflows/auto-publish.yml

name: Auto publish and create release
on:
  push:
    branches:
      - master
            - next
  pull_request:
    branches:
      - master
jobs:
  autorelease:
    runs-on: ubuntu-latest
    if: "!contains(github.event.head_commit.message, 'ci skip') && !contains(github.event.head_commit.message, 'skip ci')"
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - run: git fetch --unshallow --tags
      - name: Setup node
        uses: actions/setup-node@v1
        with:
          node-version: '12.x'
          registry-url: 'https://registry.npmjs.org'
      - name: Auto release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
        run: |
          npm ci
          npx auto shipit

Note:

Creating new releases on merging pull request to master
Creating pre releases on merging pull request to next

on:
  push:
    branches:
      - master
            - next

Create canary release when a PR is created against master

on:
 pull_request:
    branches:
      - master

Do not run auto when it makes changes to CHANGELOG to not get stuck in a release loop.

if: "!contains(github.event.head_commit.message, 'ci skip') && !contains(github.event.head_commit.message, 'skip ci')"

Handle installing private package if you have any

 - name: Setup node
        uses: actions/setup-node@v1
        with:
          node-version: '12.x'
          registry-url: 'https://registry.npmjs.org'

and

NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Enjoy your new release process 🚀

PS: The documentation also have an example for GitHub action: https://intuit.github.io/auto/docs/build-platforms/github-actions

GitHub Action, Cypress and Percy parallelisation setup

Aurore T — Sat, 21 Mar 2020 15:44:33 +0000

Recently, I moved our Cypress test suite over to GitHub Action, and I had trouble finding a full example of how to run Cypress and Percy together using parallelisation to run the tests quicker. Here is an example of how to do this.

I will assume if you ended up here, you know what all of those tools do.

Full example

In your repo, in .github/workflows/main.yml:

name: End-to-end tests
on:
  pull_request:
    branches:
      - develop
jobs:
  cypress-run:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        containers: [1, 2, 3, 4, 5, 6]
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Setup node
        uses: actions/setup-node@v1
        with:
          node-version: '10.x'
          registry-url: 'https://registry.npmjs.org'
      - name: Install dependencies
        run: npm ci
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
      - name: Cypress run
        uses: cypress-io/github-action@v1
        with:
          install: false
          start: npm start
          wait-on: 'http://localhost:8080/'
          record: true
          parallel: true
          command-prefix: 'percy exec -- npx'
        env:
          CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
          PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }}
          PERCY_PARALLEL_TOTAL: 6
          PERCY_PARALLEL_NONCE: '${{ github.event_name }}-${{ github.sha }}'
          PERCY_TARGET_BRANCH: 'develop'
          PERCY_BRANCH: ${{ github.head_ref }}
          COMMIT_INFO_BRANCH: ${{ github.head_ref }}

For any environment variables, use GitHub secrets to save them and access them in the GitHub action.

Breaking it down

Running test on pull request to the develop branch

name: End-to-end tests
on:
  pull_request:
    branches:
      - develop

Start the job and runs it on 6 ubuntu machines. In case of errors, do not cancel other actions (fail-fast: false)

jobs:
  cypress-run:
  runs-on: ubuntu-latest
  strategy:
    fail-fast: false
    matrix:
      containers: [1, 2, 3, 4, 5, 6]

Checkout the repo

steps:
  - name: Checkout
    uses: actions/checkout@v2

Set up node 10.x

- name: Setup node
  uses: actions/setup-node@v1
  with:
    node-version: '10.x'
    registry-url: 'https://registry.npmjs.org'

Install npm dependencies with NPM TOKEN for private repo

- name: Install dependencies
  run: npm ci
    env:
      NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

For running the cypress test, we are using the Cypress GitHub action. Here is the cypress doc which is pretty good but here is a breakdown as well:
- Cypress action configuration
  - install: false Do not install dependencies as we've done it ourselves
  - start: npm start Command to run to start the app
  - wait-on: 'http://localhost:8080/' wait for the app to be started on this url to start testing
  - record: true Record the test in Cypress dashboard
  - parallel: true Runs the test in parallel
  - command-prefix: 'percy exec -- npx' Command to be prefixed to the cypress command run by the action
- Environment variables
  - CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }: Cypress record key
  - PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }: Percy token
  - PERCY_PARALLEL_TOTAL: 6: The number of server used for parallelisation
  - PERCY_PARALLEL_NONCE: '${{ github.event_name }}-${{ github.sha }}': Unique ID for Percy to link builds on each machine together
  - PERCY_TARGET_BRANCH: 'develop' Target branch used by Percy to compare against
  - PERCY_BRANCH: ${{ github.head_ref }} Name to display in Percy for the branch this is being run for
  - COMMIT_INFO_BRANCH: ${{ github.head_ref }} Name to display in Cypress for the branch this is being run for

- name: Cypress run
  uses: cypress-io/github-action@v1
  with:
    install: false
    start: npm start
    wait-on: 'http://localhost:8080/'
    record: true
    parallel: true
    command-prefix: 'percy exec -- npx'
  env:
    CYPRESS_RECORD_KEY: ${{ secrets.CYPRESS_RECORD_KEY }}
    PERCY_TOKEN: ${{ secrets.PERCY_TOKEN }}
    PERCY_PARALLEL_TOTAL: 6
    PERCY_PARALLEL_NONCE: '${{ github.event_name }}-${{ github.sha }}'
    PERCY_TARGET_BRANCH: 'develop'
    PERCY_BRANCH: ${{ github.head_ref }}
    COMMIT_INFO_BRANCH: ${{ github.head_ref }}

I hope this is useful, comment below if you have any questions.
Happy testing 🎉

How to use stub multiple API requests dynamically in Cypress

Aurore T — Wed, 12 Feb 2020 20:11:00 +0000

Update: You can now to this with Cypress new intercept command 🎉: https://www.cypress.io/blog/2020/11/24/introducing-cy-intercept-next-generation-network-stubbing-in-cypress-6-0/

Recently, as part of refactoring on how we handle mocking Cypress network request, I had to find a way to mock the same request made multiple times but with different responses in our test suite.

At the moment, with Cypress, there is no way you can make the mock results dynamic depending on what was requested.

The problem

We have a POST request made to a very simple endpoint. Depending on the request, we get different results.

We already have a very long file with non-formatted JSON responses that are linked to the request using a matching object to match the request payload to a specific answer dynamically. So we already have some of the logic here, which will take ages to extract or break down. Ideally, we want to reuse this.

Some of the cypress default commands were overwritten ( routes and visit) to handle this case, as well as mocking fetch.

We moved away from this and removed those to use the default cypress commands. We are using the trick describe here to mock fetch. Now we need to handle the dynamic stubbing part as well.

The solution

This is inspired from a comment on this Cypress issue on GitHub related allowing dynamic stubbing.

We have added a new command to mock request to our endpoint dynamically on-demand using xhook (library to intercept and modify XHR request and responses) :

// commands.js 
    Cypress.Commands.add('mockArticlesRequest', () => {
      Cypress.once('window:before:load', window => {
        const script = window.document.createElement('script');
        script.onload = function() {
          window.xhook.after((request, response) => {
            const { method, url, body } = request;
            if (
              method === 'POST' &&
              (url.endsWith('/articles'))
            ) {
              const articlesResponses = require('../fixtures/responses.json');
              const parsedBody = JSON.parse(body);
              const newResponse = articlesResponses.find(({ matches }) =>
                Object.keys(matches).every(
                  key =>
                    JSON.stringify(parsedBody[key]) === JSON.stringify(matches[key])
                )
              );
              if (!newResponse) {
                return;
              }
              response.data = JSON.stringify(newResponse.response);
              response.text = JSON.stringify(newResponse.response);
            }
          });
        };
        script.src = '//unpkg.com/xhook@latest/dist/xhook.min.js';
        script.id = 'xhook';
        window.document.head.appendChild(script);
      });
    });

I'm using Cypress.once so xhook script is not added to other tests on page load.

Then in a test file where calls to that endpoint will be made, we use

// articles.spec.js
describe('Articles page', () => {
  beforeEach(() => {
    cy.mockArticlesRequest();
    cy.server();
    cy.route('/user', 'fixture:user.json');
     ...
  });
});

And this what the fixture response file look like:

// fixtures/responses.json
{
  "matches": {
    "id": 1
  },
  "response": {
    "data": [{
      ...
   }]
  }
}

And that's it 🎉 Happy testing 🚀

Note: There seems to an issue where this doesn't work when cy.clock is used.

Nightwatch + Browserstack

Aurore T — Thu, 18 Oct 2018 17:56:34 +0000

Vue cli 2: Nightwatch + Browserstack

Recently, I had to configure the Nightwatch test we have on our Vue.js project to be able to run on Browserstack automated testing platform. This had to work for different environments. We have two main environments: test and prods.

The configuration we wanted to achieve was to be able to run the e2e test on:

localhost using local selenium and Chromedriver.
test/prod URLs using local selenium and Chromedriver
test/prod URLs uring Browserstack

The final files are at the end of this article which you can paste from.

Initial setup

Our application is using Vue.js and was generated with vue cli 2 using the webpack template. We have a runner.js file, which is used to set up webpack, to be able to run the test on localhost. We will have to update this runner.js file and the nightwatch config.

Configuring Browserstack to only run on test/prod environments

Browserstack has a nice document on how to run Nightwatch test suite with them. The only problem is they assume you want to run on Browserstack all the time and do not show examples to have it configurable. What if you want to use a local version of Selenium and Chrome? It also gets more complex when you have to use Browserstack local to be able to access internal URLs, which was our case.

In order to run Browserstack local, you need to use a specific setup, which is set in a different runner file in their documentation.

1. Runner.js updates

In the runner, to use Browserstack local, we made it configurable using the command line node environment variable. We are expecting a variable we called RUNNER to be present, to specify which runner to use: local or Browserstack.

If the test needs to be run on Browserstack, we set up the runner to use Browserstack local. If not, we use the default configuration to set up the server, which is the same code provided by the Browserstack documentation.

Using Browserstack local when running the test on Browserstack

2. Nightwatch config updates

Our config by default is using the local selenium. If the node environment variable RUNNERis provided to execute test on browserstack, we are overriding those settings to use Browserstack selenium (similar to the Browserstack documentation).

Overriding Nightwatch config to use Browserstack selenium

3. Update test status in Browserstack through API

By default, when executing the test, Browserstack won’t be able to show if a test failed. The only way to update this is by making a request to Browserstack API.

The request needs the session ID, which is available in the test or in the global afterEach executed at the end of each test suite. In the nightwatch config file, you can set this in globals property. If the test failed, we make a request to set them to fail. We also update the name to show of the session to display which environment the test was executed on: test or prod.

Setting test session in Browserstack as failure or success

Final files

Thanks for reading, I hope this is helpful. I am planning on looking at how to do the same using Vue CLI 3 and write an article too. I will add a link here when it happens.

Update: here is the article with the Vue cli 3: https://medium.com/@digitaledawn/vue-cli-3-nightwatch-browserstack-76c61a0fbb79