Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Github Action #619

Closed
nikoloza opened this issue Jun 23, 2021 · 4 comments
Closed

Github Action #619

nikoloza opened this issue Jun 23, 2021 · 4 comments

Comments

@nikoloza
Copy link

I'd like to automate bumping version on every push to main or PR merge. Could not find any np related GH Action on that matter

@nikoloza nikoloza changed the title Github Action on push Github Action Jun 23, 2021
@dopecodez
Copy link
Collaborator

np is a better publish not just a npm version updater. Do you want a github action which will just update the version in the package.json file?

@smeijer
Copy link

smeijer commented Aug 17, 2021

I think an action like this could be created if the next version could be determined by the recent commit messages. But for that, it would need to understand the commit convention (patch for fixes, minor for features, major when breaking).

@fregante
Copy link
Collaborator

I don’t think it makes much sense for this to exist. Let's see the feature list

  • Interactive UI
    • ❌ Impossible on GHA
  • Ensures you are publishing from your release branch (main and master by default)
    • 🤷‍♂️ Native on GHA
  • Ensures the working directory is clean and that there are no unpulled changes
    • 🤷‍♂️ Native on GHA
  • Reinstalls dependencies to ensure your project works with the latest dependency tree
    • 🤷‍♂️ Native on GHA
  • Ensures your Node.js and npm versions are supported by the project and its dependencies
    • 🤷‍♂️ Native on GHA
  • Runs the tests
    • 🤷‍♂️ Native on GHA
  • Bumps the version in package.json and npm-shrinkwrap.json (if present) and creates a git tag
    • 🤷‍♂️ Native with npm
  • Prevents accidental publishing of pre-release versions under the latest dist-tag
    • 👉 I guess this
  • Publishes the new version to npm, optionally under a dist-tag
    • 🤷‍♂️ Native with npm
  • Rolls back the project to its previous state in case publishing fails
    • 🤷‍♂️ Native on GHA
  • Pushes commits and tags (newly & previously created) to GitHub/GitLab
    • 🤷‍♂️ Possible with regular git push
  • Supports two-factor authentication
    • ❌ Impossible on GHA
  • Enables two-factor authentication on new repositories
    • 🤷‍♂️ It doesn't make sense for a pre-existing repo on GHA
  • Opens a prefilled GitHub Releases draft after publish
  • Warns about the possibility of extraneous files being published
    • 👉 This, but what is it going to do? Block the release? GHA is not interactive
  • See exactly what will be executed with preview mode, without pushing or publishing anything remotely
    • 🤷‍♂️ Native by calling npm pack on every CI run
  • Supports GitHub Packages
    • 🤷‍♂️ Native with npm

@revelt
Copy link
Contributor

revelt commented Oct 26, 2022

If anybody's interested into automating the versioning, it can be done using lerna and conventional commits. See my TS monorepo for a working setup example. There are important points which affect the setup, and yours might be different:

  1. that's a monorepo of npm packages-programs (not packages-components or anything to do with front-end/React/Angular etc),
  2. it's all on TypeScript (I keep non TS libraries as separate repos to simplify the monorepo),
  3. all packages are pure-ESM, including CLI's; I'm not producing any CJS builds, only ESM and in many cases IIFE for browsers (esbuid can't do CJS or UMD).
  4. it's a stateful devops setup, that is, CI produces build artifacts and commits them. That can be avoided and you can see it in projects where there's no version field in package.json, take Facebook projects for example — nothing in package.json is mentioning any version-specific information.

Quick overview of such setup:

  1. you'd always commit by calling git-cz -n, I set up cm npm script to trigger the CLI — each commit gets formatted properly so that later lerna --conventional-commits can recognise them and calculate correct versions — see here
  2. enable conventional commits in lerna config — see here
  3. it's a long story but I'm not using lerna publish; I only bump versions using lerna version. Practically, that's turbo script turbo run letspublish which calls letspublish script in each package which looks like this yarn publish || :. The assumption is, unbumped packages will refuse to publish, but since process exits with non-zero code, we append || :. The reason behind not using lerna publish is I want to granularly control what and when gets pushed to remote.
  4. I had a botched release months ago similar to this; the CI was authenticated, build artifacts were committed on remote, with git tags and all — and — npm refused to npm publish. In the end, I switched to yarn publish and it magically worked again. That's why I'm still sticking with yarn (also turbo allegedly has better integration on yarn projects, don't know if it's still true).
  5. The version calculation still fails in some cases, for example, if you migrate from GitHub to let's say SourceHut, version calculation will count the "from" state since the start of the git repository existence, so any package which has ever had a "breaking" type commit will be major semver-bumped. In my case, tens of packages accidentally got major-bumped. Theoretically, if time and resources were unlimited, we'd draw up a "staging" npm instance and test each release there first, reviewing all versions.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants