Closed tschaffter closed 4 years ago
This PR is ready for review. This PR aims to resolve #24 and #53.
The GitHub workflow ci.yml
should be self explanatory. A high level description and motivations for the choices made are given below.
lint
, test
and publish
. I'm actually going to comment lint
until we decide to lint files in this repo.test
is executed when pushing to master
and develop
and when pushing to the base branch of a PR.test
includes a step to push the coverage report to Coveralls.publish
is only run when creating a GitHub release.
name
and version
fields in the package.json are used to publish the release to npmjsNPM_TOKEN
--access public
for npm publish
makes the release public.travis.yml
has been removed)From past discussions, it sounds like we agree to use Gitflow / Hubflow for this repo. Here is what the release protocol could be:
develop
, for example named release-<version>
master
and develop
master
@jaeddy The npmjs package below has been created automatically using the GH Action proposed in this PR.
https://www.npmjs.com/package/gh-openapi-docs-test
This package has been generated when I created this GH release
https://github.com/tschaffter/gh-openapi-docs/releases/tag/20200913-3
Here is the GH Action run that shows the logs
https://github.com/tschaffter/gh-openapi-docs/actions/runs/252577012
Thanks, @tschaffter! Is it straightforward to modify the workflow so that test
runs on all branches and PRs? Seems like we'd want to have that as a universal check.
For the release process, it'd be nice to have steps (4) and (5) automated (triggered whenever a release branch is merged into master
) as part of the workflow — maybe a tag_and_release
job (or whatever other name makes sense). We can probably add that in a separate PR though.
@jaeddy The GH worflow now runs for commits pushed to all branches
on:
push:
branches:
- '**'
release:
types:
- created
pull_request:
For the release process, it'd be nice to have steps (4) and (5) automated (triggered whenever a release branch is merged into master) as part of the workflow — maybe a tag_and_release job (or whatever other name makes sense). We can probably add that in a separate PR though.
If you agree, let's merge this PR to switch to GitHub workflow for CI/CD. I'll then open a second PR to address what you describe above.
Thanks, @tschaffter! Just to clarify, the workflow will (a) run tests on all branches; but (b) only publish when a release is created (i.e., not for every branch)?
Correct! The job publish
is run only when this condition is met:
publish:
if: github.event_name == 'release' && github.event.action == 'created'
Tasks to perform in this workflow: