-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ci: add generic version bump and pr testing and relese workflows for nodejs #21
Conversation
.github/workflows/version-bump.yml
Outdated
# We make sure here no tags are added by default as they are already added by release workflow | ||
# --allow-same-version is set in case someone forgot and updated package.json manually and we want to avoide this action to fail and raise confusion | ||
# run: npm --no-git-tag-version --allow-same-version version ${{github.event.release.tag_name}} | ||
run: VERSION=${{github.event.release.tag_name}} npm bump:version |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is done this way, with exporting version as environment variable as it is easier this way to later implement npm bump:version
script in monorepos
.github/workflows/version-bump.yml
Outdated
- name: Check if Node.js project and has package.json | ||
id: packagejson | ||
run: test -e ./package.json && "::set-output name=exists::true" || "::set-output name=exists::false" | ||
- if: steps.packagejson.outputs.exists == 'true' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, we need to put if
to every step instead of doing one step with if that checks false
and then gracefully stops the job. Why? as github action runner doesn't support that yet :( actions/runner#662
this is what happens to release workflow after removing bump and or creation from it -> asyncapi/html-template#125 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When this is approved, how will it handle templates which does not contain these new scripts, will it just fail the task @derberg ?
@jonaslagoni it won't handle them gracefully. The job will fail. But it is not a problem as it won't happen 😄
So this one is not merged until PRs from all the other repos are merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
@jonaslagoni awesome. What do you think about taking the same approach (generic nodejs workflow with first step that checks if package.json is there) for PR testing and release workflow in general -> https://github.com/asyncapi/html-template/pull/125/files#r555705827 |
@derberg I dont have any objections in standardize the release process for npm repositories 👍 |
@jonaslagoni I'll update this PR then, let's see how it will look like |
ok, now this PR has 3 new global workflows that will run on nodejs projects only. I don't like this:
but there is no alternative now, spent some more hours on investigation. Light in the tunnel for the future is that we could just do the following condition on a job level |
@jonaslagoni I updated this PR with generic workflows for release and pr testing. As a result, this is how it will look like in other projects once this PR is merged -> https://github.com/asyncapi/html-template/pull/125/files Looks promising but as mentioned before now I will do the cleanup in a most complex project, react component |
@jonaslagoni @magicmatatjahu I updated this PR, including the description. I think it is awesome that we can have generic release workflow for all nodejs projects. All workflows tested against asyncapi-react with success Of course, this is not going to be merged once I cleanup release workflows across all repos |
d7f411d
to
84f8eb8
Compare
Description
package.json
is in the rootversion bump
generate:assets
that will run scripts like the ones about generating docs. toc in readme or typesbump:version
that will run scripts to bump version of the package in package.jsonpr testing
release workflow
This is what I'm happy with the most, that was not my intention at the beginning but after testing it with React component that had the most complicated release workflow I'm now sure that we can have a simple generic release workflow that can be easily extended per repo with the approach we did in react https://github.com/asyncapi/asyncapi-react/blob/master/.github/workflows/release-wc-and-playground.yml
Related issue(s)
See also asyncapi/spec#423