Move from Travis to GitHub Actions about browser-extension-template HOT 10 CLOSED

After some extensive testing, this is what I came up with (that works, partly, see explanation below):

name: Deployment to Stores
on:
  push:
    tags:
      - hotfix
  schedule:
    - cron: 0 0 * * * # Daily
jobs:
  untag:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - if: contains(github.ref, 'hotfix')
      env:
        GH_TOKEN: ${{ secrets.GH_TOKEN }}
      run: |
        git remote set-url origin "https://${GITHUB_REPOSITORY%/*}:[email protected]/$GITHUB_REPOSITORY.git"
        git push --delete origin hotfix
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: npm install
    - run: npm test
    - run: npm run build
  publish:
    needs: test
    runs-on: ubuntu-latest
    steps:
     - uses: actions/checkout@v1
     - run: npm install
     - run: npm run build
     - run: echo "Releasing to AMO" # Equivalent to "npm run release:aws"
     - run: echo "Releasing to CWS" # Equivalent to "npm run release:cws"
     - uses: actions/upload-artifact@v1
       with:
        name: built-extension
        path: distribution
  tag:
    needs: publish
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: npm install
    - env:
        GH_TOKEN: ${{ secrets.GH_TOKEN }}
        GH_NAME: ${{ secrets.GH_NAME }}
        GH_EMAIL: ${{ secrets.GH_EMAIL }}
      run: |
        git remote set-url origin "https://${GITHUB_REPOSITORY%/*}:[email protected]/$GITHUB_REPOSITORY.git"
        
        git config --global user.name "${GH_NAME}"
        git config --global user.email "${GH_EMAIL}"
        
        VERSION=$(./node_modules/.bin/daily-version)
        
        git tag $VERSION -m $VERSION
        git push origin $VERSION

I think we'd have to run all the deployment stages (like building, publishing, and tagging) in the same job so that all the commands run in the same directory.

It looks like each GHA job is assigned to with a new directory, so changes done to a directory in a GHA job are not available in the other GHA job, so all of building, publishing, and pushing tags need to be done in the same job. I might be wrong about this, but that's what I understand about GHA as of now.

As you can see that the above sample script has flaws, where we need access to $VERSION in publish job, but that's being initialized in the tags job, using daily-version in both these instances here is fine, but some other scripts like utc-version might end up giving different values when run both the GHA jobs (hence the need to place all the scripts in a single GHA job, except for untagging though, that can stay independent).

Deleting hotfix tag after we no longer need it works fine, by replacing it with a newly created and pushed tag. I still don't know how we should handle multiple hotfix releases made on the same day, which according to daily-version creates same tags, should tags be updated in that case or something else needs to be done? That remains a question.

And also we still don't have reliable way to have custom condition to test for any new commits in the last 24 hours, and possibly stop execution of GHA jobs without them being marked as failed GHA jobs (this is required).

from browser-extension-template.

Just tested GitHub Actions Beta, surprisingly the build runs are amazingly fast, don't know how GH is doing that.

About ease of setup, the configuration file does feel intuitive to use and write, except being very verbose at times like having to specifically mention actions to clone the repo and to telling which version of Node to install (in each workflow file).

One advantage I see using GH Actions is being able to specify multiple build files giving fine grain control on what can be done, but again the downside being it's not mature enough as Travis is.

Your secret environment variables now go into GitHub secrets (not that big of a problem though), some other problems that I found is not being able to re-run passed checks, and there's no info at all on how CRON jobs are run and when the next run is scheduled to be 🤷‍♂️ 😕 😵.

I'm not complaining here, just pointing out some differences from existing CI/CD tools. Considering the new GH Actions are new and are in early beta to complain anything about, can't make any decisions yet.

Having said that, I'm still skeptical about if GH is going to break anything going forward (beta), and on how people cloning this repo to other Git platforms like GitLab will be able to have the tests run.

Just some thoughts.

from browser-extension-template.

Configuration for this should be relatively simple but there doesn’t seem to be a way to manually trigger a workflow yet:

https://github.community/t5/GitHub-Actions/GitHub-Actions-Manual-Trigger-Approvals/td-p/31504

So it can’t be done yet.

from browser-extension-template.

… unless there’s a way to configure it to run when a collaborator included a keyword on PR comment. This could be possible.

from browser-extension-template.

There's a way: hotfix tag that is deleted once the deployment is done.

The good part of GitHub Actions is that they have push access to the repo, so moving to GHA would enable:

• creating tags (like RGH complicately does) including proper releases with changelogs (e.g. the output of git show (since last tag))
• deploying to stores in 2 separate "jobs", so they're completely isolated and any of them can create a tag. Currently RGH only creates a tag if both are successful.

This is what a plain test job looks like: https://github.com/sindresorhus/refined-github/blob/master/.github/workflows/test.yml

from browser-extension-template.

Example, untested. It's missing:

• The deployment condition, matching $(git tag -l --points-at HEAD) = "") via https://help.github.com/en/articles/workflow-syntax-for-github-actions#jobsjob_idstepsif

name: Deployment
on:
  push:
    tags:
      - hotfix
  schedule:
    - cron:  '0 0 15 1/1 * ? *' # Daily
jobs:
  untag:
    steps:
    - uses: actions/checkout@v1
    - if: contains(github.ref, 'hotfix')
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        git remote set-url origin "https://${GITHUB_REPOSITORY%/*}:[email protected]/$GITHUB_REPOSITORY.git"
        git push --delete origin hotfix
  test:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: npm ci
    - run: npm test
    - uses: actions/upload-artifact@v1
      with:
        name: built-extension
        path: distribution
  firefox:
    needs: test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: npm ci
    - run: run-s prelease:* release:amo
  chrome:
    needs: test
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: npm ci
    - run: run-s prelease:* release:cws
  tag:
    needs: [firefox, chrome]
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: npm ci
    - env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      run: |
        git remote set-url origin "https://${GITHUB_REPOSITORY%/*}:[email protected]/$GITHUB_REPOSITORY.git"
        VERSION=$(daily-version)
        git tag $VERSION -m $VERSION
        git push origin $VERSION

from browser-extension-template.

Thanks for testing!

A couple of notes:

1. We can use the upload-artifacts/download-artifacts to build it only once, if necessary. The test stage could look like:

    - uses: actions/checkout@v1
    - run: npm ci # this is faster than `npm install`
    - run: npm run test
    - run: run-p prelease:* # This will set the version in the zip file
    - uses: actions/upload-artifact@v1
      with:
       name: built-extension
       path: distribution

2. daily-version actually looks for today's tag; if y.m.d already exists it will use y.m.d.hmm automatically. daily-version doesn't care nor look for hotfix. But you're right, it should only be called once.

3. The version can also be generated once in an early job and then reused later. Jobs have an output value but I don't know how to set it.

   Output parameters allow you to specify the data that subsequent actions can use later in the workflow after the action that defines these outputs has run

   Alternatively we can just save it as a file and upload it as an artifact:

    - run: npx daily-version > version.txt # `npx` lets us skip `npm install`
    - uses: actions/upload-artifact@v1
      with:
       name: version
       path: version.txt

4. Having GHA run the deploy scripts separately is a plus. A while ago we kept having problems with the scripts interfering with each other when they failed, so if they're isolated this won't happen anymore, even if that means running npm ci multiple times.

And also we still don't have reliable way to have custom condition to test for any new commits in the last 24 hours, and possibly stop execution of GHA jobs without them being marked as failed GHA jobs (this is required).

Yeah, this is a big one. I don't know if there's a way to block a whole workflow based on a condition, it might be worth asking on https://github.community

Apparently, Jobs used to have a neutral status, meaning that they wouldn't be neither successful nor failures. This would be perfect to have a "condition" job that exits with neutral when no new version is necessary.

from browser-extension-template.

Also if you want to open a PR with that file on the next iteration we can comment on the lines

from browser-extension-template.

Edit: I might have found a solution but it's just too long. Let's stick to Travis until neutral becomes available again.

jobs:
  should-release:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - run: |
        if ! [ $(git tag -l --points-at HEAD) = "") ]; then
            false; # Cancel release
        endif

    # This will mark the release as "should release" so we don't catch ALL errors
    - run: echo 1 > should-release
    - uses: actions/upload-artifact@v1
      with:
        name: should-release
        path: should-release

  ... other jobs, they'll be skipped if they have `needs: should-release` ...

  catch-failure:
    runs-on: ubuntu-latest
    needs: should-release
    steps:
    - if: failure() # this should restore a positive status

    - uses: actions/download-artifact@v1
      with:
        name: should-release
    - run: |
        if [ -f "$FILE" ]; then 
            false; # The file exists, therefore the failure was not due to `should-release` but it happened in the regular build/deployment
        endif

from browser-extension-template.

Ok, I got it. We can do this in 2 actions:

A. runs daily and only creates a deploy tag if necessary
B. just deploys on deploy tag

# deploy-daily.yml
name: Daily deployment check
on:
  schedule:
    - cron: '0 0 * * *' # Daily

jobs:
  create-tag:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: fregante/setup-git-token@v1
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
    - if: .... git condition here...
      run: git push origin HEAD:refs/tags/deploy

# deploy.yml
name: Deployment
on:
  push:
    tags:
      - deploy

jobs:

  # etc, deploy to stores without condition

  # then delete `deploy` tag
  delete:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: fregante/setup-git-token@v1
      with:
        token: ${{ secrets.GITHUB_TOKEN }}
    - run: git push --delete origin deploy

from browser-extension-template.