chore: Publish canary version on PRs to develop

[olivermrbl]

What
Publish versions on pull requests to branch develop

Why
To be able to get versions with small fixes or features out to users immediately

How
Using a GitHub action, we:

• Build all packages
• Format the branch to be used as version name
• Publish versions of all changed packages with formatted version name

When formatting the branch name we replace all special characters with -, so a branch like feat/test-this_action will have a canary version called feat-test-this-action.

[srindom]

Two things:

1. I don't think it is necessary to do the bootstrap and build - if you run lerna publish locally it builds before publishing.

2. Should we force publish?

[adrien2p]

Do you really think a version for each PR on develop is a good idea? a PR can be broken, un needed, wrong etc... and therefore the version as well.
What we could do is when something is merged on the develop branch then we create a new beta version from develop instead ?

[olivermrbl]

What we could do is when something is merged on the develop branch then we create a new beta version from develop instead ?

I don't see any harm in publishing canary versions for all PRs to develop tbh. Thing is, when we are building on admin and core simultaneously, the canary versions will ensure, that we are never blocked due to a hanging PR or new release.

Additionally, these versions allow devs. to quickly test out the feature giving us shorter time to feedback.

We are also planning on adding a pipeline for deploying a canary version with tag develop 👍

[olivermrbl]

I don't see any harm in publishing canary versions for all PRs to develop tbh

One thing we could do is to only run the publishing job, if all tests are successful @adrien2p

[pKorsholm]

Great idea, I love this.

Wrt. the canary for develop can I think we can get two birds with one stone and encapsulate the entire workflow in a single, separate, workflow file.

Github actions can have [multiple triggers](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#using-activity-types-and-filters-with-multiple-events) and support triggers based on the [completion of previous workflows](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_run). If we combine this we should be able to create a separate workflow that runs when develop is pushed (or a different develop event), as well as whenever the pipeline has concluded.

I think it could look something like this:

name: Publish Canary

on:
  push:
    branches: [develop]
  workflow_run:
    workflows: ["Medusa Pipeline"]
    types:
      - completed

jobs:
  publish:
    runs-on: ubuntu-latest
    if: ${{ github.event.workflow_run.conclusion == 'success' || github.event.ref == 'refs/heads/develop' }}
    steps:
      - name: Checkout
        uses: actions/checkout@v2.3.5
        with:
          fetch-depth: 0

      - name: Setup Node.js environment
        uses: actions/setup-node@v2.4.1
        with:
          node-version: "14"
          cache: "yarn"
          registry-url: "https://registry.npmjs.org"
      - name: "Get Branch Name"
        run: |
          BRANCH_NAME="${GITHUB_HEAD_REF}"
          echo "BRANCH_NAME=${BRANCH_NAME}" >> $GITHUB_ENV
      - name: Format Version Name
        run: |
          VERSION_NAME=`echo ${{ env.BRANCH_NAME }} | sed "s/[/_]/-/g"`
          echo "VERSION_NAME=${VERSION_NAME}" >> $GITHUB_ENV
      - name: Authenticate with NPM
        run: |
          echo "@oliverjuhl:registry=http://registry.npmjs.org/" > .npmrc
          echo "registry=http://registry.npmjs.org/" >> .npmrc
          echo "//registry.npmjs.org/:_authToken=$NPM_TOKEN" >> .npmrc
          npm whoami
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
      - name: Publish Canary
        run: lerna publish --yes --canary --preid ${{ env.VERSION_NAME }} --dist-tag ${{ env.VERSION_NAME }} --force-publish="*"
        env:
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

[adrien2p]

LGTM 🚀 just few comments

[adrien2p]

question: why do we have to check the ref here since it is on push to develop?

[adrien2p]

suggestion: we should probably add a step to stop previous same workflow in order to avoid situations where we push 10 new versions when we merge ten branches 😅

[olivermrbl]

Wrt. the canary for develop can I think we can get two birds with one stone and encapsulate the entire workflow in a single, separate, workflow file.

Great suggestion @pKorsholm - thanks!

@adrien2p

question: why do we have to check the ref here since it is on push to develop?

As @pKorsholm mentions, we now encapsulate the publishing of canary versions for all PRs opened to develop as well as when develop is pushed in a single file and workflow, hence why we need the ref check.

Update: I now see, that it's only on push to develop. We should add a trigger for pull requests to develop as well to support the first case from my previous comment. I'll play around with it and report back

[adrien2p]

suggestion:
on: ["push","pull_request"] if it is possible? 😊

[adrien2p]

Update: I now see, that it's only on push to develop. We should add a trigger for pull requests to develop as well to support the first case from my previous comment. I'll play around with it and report back

No problem, do we also want to to be triggered for forked repository that open a pr?

[pKorsholm]

Can we wait to merge this for a bit. Just a consideration, we should probably have a special canary package listed as well and publish versions to that rather than the release package.

Versions bloat the json downloaded when installing, and this might not be an issue now, but if it is ever growing it might hurt us in like 10.000 publishes 😅

[olivermrbl]

Closed in favor of #1746