Skip to content
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

feat: release binaries #105

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

feat: release binaries #105

wants to merge 1 commit into from

Conversation

marco-ippolito
Copy link
Member

No description provided.

@marco-ippolito marco-ippolito force-pushed the pack-some-bins branch 11 times, most recently from 9878c46 to 52a82e6 Compare March 18, 2025 11:17
@edezekiel
Copy link

edezekiel commented Mar 18, 2025

I think the command oclif pack tarballs -t <platform-targets[]> supports targeting multiple platforms without needing multiple package.jsons.[1] This PR just uses oclif pack <target>.

The documentation isn't super clear on how the tarballs command works though.[2] For example it's unclear whether you wind up with multiple node bins in a single package.
[1]https://github.com/oclif/oclif/blob/main/src%2Fcommands%2Fpack%2Ftarballs.ts
[2]https://oclif.io/docs/releasing#standalone-tarballs

@marco-ippolito marco-ippolito force-pushed the pack-some-bins branch 12 times, most recently from 326bb64 to 70b220c Compare March 18, 2025 15:05
@marco-ippolito marco-ippolito changed the base branch from dtw/oclif-rewrite-again to dev March 18, 2025 15:05
@@ -17,7 +16,7 @@ $ npm install -g @herodevs/cli
$ hd COMMAND
running command...
$ hd (--version)
@herodevs/cli/2.0.0 darwin-arm64 node-v22.14.0
@herodevs/cli/2.0.0 darwin-arm64 node-v22.13.0
Copy link

@edezekiel edezekiel Mar 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: should this be @herodevs/cli/1.0.0-beta This comment also applies to all other instances of @herodevs/cli/2.0.0 (and "version": "2.0.0") in this PR

],
"license": "MIT",
"optionalDependencies": {
"@herodevs/cli-darwin-arm64": "^2.0.0",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: should this be @herodevs/cli/1.0.0-beta (for each optional dependency)

"version": "2.0.0",
"name": "@herodevs/monorepo",
"private": true,
"version": "0.0.0",

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: should this be @herodevs/cli/1.0.0-beta

@@ -0,0 +1 @@
#!/usr/bin/env node

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the script that will eventually become the biome-like glue code?

https://github.com/biomejs/biome/blob/main/packages/%40biomejs/biome/bin/biome

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

runs-on: ${{ matrix.os }}
needs: check
env:
version: ${{ needs.check.outputs.version }}

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So with this setup, after the pull_request trigger is removed it looks like this would be how we trigger a release:

  • work on feature branch
  • push commit to feature branch chore(release): v1.0.0-beta
  • create PR into main
  • review PR, merge into main (no deployment yet)
  • manually trigger workflow_dispatch from GitHub
  • the release workflow is invoked, sees a version diff in the commit, and triggers a deployment

push:
branches:
- main
pull_request: # remove me when ready
workflow_dispatch:

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: instead of workflow_dispatch and EndBug/version-check, I'd recommend the release be triggered on pushed git tags, similar to our other product release workflows:

on:
  push:
    tags:
      - "v*.*.*"

The workflow_dispatch could then be reserved for dry runs only.

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

Successfully merging this pull request may close these issues.

2 participants