Replace Travis with GitHub Actions, remove codecov
See original GitHub issueWe want to do some maintenance to the @semantic-release repository, starting with replacing Travis with GitHub Actions.
@travi here is my current plan, does it cover everything? I’d do it manually in this repository, confirm that we didn’t miss anything, then codify it for the remaining repositories using https://github.com/gr2m/mutate-github-repositories-cli
-
Delete
.travis
file -
Remove Travis & Codecov badges from README.
-
Enforce 100% code coverage by updating
package.json
"nyc": { "include": [ "lib/**/*.js", "index.js" ], "reporter": [ "json", "text", "html" ], - "all": true + "all": true, + "check-coverage": true, + "branches": 100, + "lines": 100, + "functions": 100, + "statements": 100 },
-
Create
.github/workflows/test.yml
with the following contentname: Test "on": push: branches: - master - next - beta - *.x pull_request: types: - opened - synchronize jobs: test: runs-on: ubuntu-latest strategy: matrix: node_version: - 10.8 - 12 - 14 steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v1 with: version: "${{ matrix.node_version }}" - run: npm install - run: npm run test
-
Create
.github/workflows/release.yml
with the following contenton: push: branches: - master - next - beta - "*.x" # maintenance releases such as 15.x name: Release jobs: build: name: release runs-on: ubuntu-latest steps: - uses: actions/checkout@v2 - uses: actions/setup-node@v1 with: node-version: 12 - run: npm install - run: npx semantic-release env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
-
Add secret to the @semantic-release org:
NPM_TOKEN
(publish token for https://www.npmjs.com/~semantic-release-bot) -
Remove Codecov app installation and required status check from branch protection
Issue Analytics
- State:
- Created 3 years ago
- Comments:6 (6 by maintainers)
I think we are good to close this?
i think this is a good option and think the combination of both can actually make sense. i’m usually not a huge fan of specific coverage metrics, but i think it makes a lot of sense for projects like this that expect outside contribution.
works for me
this doc looks familiar. i think this
plus
give us enough of an answer to say that restricting IP addresses isnt realistic. i’ll admit that i’ve considered going as far as creating a bot that could rotate the token each time IP address list changes, but i havent looked very far into it yet.
i think this is a good approach to consider, but maybe its not worth complicating moving the rest of this forward to accomplish this, especially considering that we dont currently have
.nvmrc
in use