Skip to content

ci: enable automated Zed extension publishing #142

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.

Sign up for GitHub

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

Open
9romise wants to merge 1 commit into
base: main
Choose a base branch
from
Open

ci: enable automated Zed extension publishing #142

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 7 additions & 8 deletions .github/workflows/publish.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,11 +44,10 @@ jobs:
VSCE_PAT: ${{secrets.VSCE_PAT}}
OVSX_PAT: ${{secrets.OVSX_PAT}}

# - name: Publish Zed Extension
# uses: huacnlee/zed-extension-action@v2
# with:
# extension-name: npmx
# push-to: npmx.dev/npmx
# env:
# # the personal access token should have "repo" & "workflow" scopes
# COMMITTER_TOKEN: ${{ secrets.COMMITTER_TOKEN }}
- name: Publish Zed Extension
uses: huacnlee/zed-extension-action@8cd592a0d24e1e41157740f1a529aeabddc88a1b # v2.0.0
with:
extension-name: npmx
push-to: 9romise/zed-extensions
env:
COMMITTER_TOKEN: ${{ secrets.COMMITTER_TOKEN }}
Comment on lines +47 to +53

@coderabbitai coderabbitai Bot Jul 22, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== workflow =="
cat -n .github/workflows/publish.yml

echo
echo "== refs and relevant usages =="
rg -n "workflow_dispatch|tags:|branches:|extension-name|tag:|push-to|COMMITTER_TOKEN|zed-extension-action" .github/workflows/publish.yml

Repository: npmx-dev/vscode-npmx

Length of output: 2247

🌐 Web query:

huacnlee zed-extension-action v2.0.0 tag input fallback current tag workflow_dispatch

💡 Result:

In the huacnlee/zed-extension-action v2.0.0, the tag input parameter is optional [1][2]. According to the official documentation, when the tag parameter is not explicitly provided, the action defaults to using the currently pushed tag from the GitHub Actions context [1][2]. Regarding your interest in how this interacts with workflow_dispatch or other triggers, if a workflow is triggered by an event that does not inherently contain a tag (such as a manual workflow_dispatch), the action will attempt to reference the "currently pushed tag." If no tag is associated with the current context or trigger, this may result in an error (e.g., issues have been reported where users encounter errors like "invalid ref" when tags are not present in the workflow trigger) [3]. There is no explicit "fallback" mechanism documented in v2.0.0 that automatically selects a different commit or branch if the tag is missing; it expects a tag to be available in the environment to function correctly [1][2]. To handle scenarios like workflow_dispatch, users typically need to ensure a tag is provided or passed dynamically via the workflow configuration [4][5].

Citations:

🌐 Web query:

huacnlee zed-extension-action README tag input workflow_dispatch

💡 Result:

When using the huacnlee/zed-extension-action, you can use the tag input to explicitly define the version to publish, which is particularly useful when triggering the action via workflow_dispatch. By default, the action uses the Git tag from the current context [1][2]. However, when running a workflow via workflow_dispatch, the context may refer to a branch (e.g., refs/heads/main) rather than a tag, which the action may reject as an invalid reference [3]. To handle this, you can define a tag input in your workflow_dispatch configuration and pass that value to the action's tag parameter [3]. Example workflow configuration: on: workflow_dispatch: inputs: tag: description: 'Tag to publish (e.g. v0.1.1)' required: true push: tags: - 'v*' jobs: release: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ inputs.tag || github.ref }} - uses: huacnlee/zed-extension-action@v2 with: extension-name: your-extension-name push-to: your-name/extensions tag: ${{ inputs.tag || github.ref_name }} env: COMMITTER_TOKEN: ${{ secrets.COMMITTER_TOKEN }} In this setup, the tag input allows the action to correctly identify the version even when triggered manually [1][3]. If no tag parameter is provided, the action defaults to the currently pushed tag [1][2].

Citations:

🌐 Web query:

github actions workflow_dispatch inputs documentation inputs.<input_id>.required

💡 Result:

In GitHub Actions, the inputs.<input_id>.required property within a workflow_dispatch event configuration is a boolean that specifies whether a particular input must be provided when triggering the workflow [1]. Key details include: * Functionality: When set to true, the input is marked as required [1]. If a user attempts to trigger the workflow via the GitHub UI, the interface will enforce the input [2]. * Default Behavior: If not explicitly set, the default value for this property is typically false (i.e., the input is optional) [1]. * Note on Implementation: While the configuration explicitly marks an input as required, this is primarily a UI and interface-level validation [2][3]. Users invoking the workflow via the REST API or GitHub CLI are responsible for providing these values as defined [2][3]. * Configuration Example: on: workflow_dispatch: inputs: logLevel: description: 'Log level' required: true default: 'warning' type: choice options: - info - warning - debug [1] You can define up to 25 inputs for a single workflow_dispatch event [1][2]. Inputs defined in this manner are accessible within the workflow using the inputs context (e.g., ${{ inputs.input_id }}) or the github.event.inputs context [1].

Citations:

🌐 Web query:

github workflow_dispatch branch_ref github.ref_name tag missing zed-extension-action

💡 Result:

When triggering a GitHub Actions workflow using the workflow_dispatch event, github.ref_name reflects the branch from which the workflow was manually triggered, not a tag, even if you intended to target a specific tag [1][2]. This is because workflow_dispatch is typically initiated against a branch reference [3][4]. If your workflow relies on github.ref_name to identify a version or tag, it will often contain the branch name (e.g., "main" or "master") rather than the expected tag name [1][2]. To resolve this, standard practice involves the following strategies: 1. Use Workflow Inputs: Define a custom input in your workflow_dispatch configuration (e.g., inputs.tag) to allow users to explicitly provide the desired tag or version [1][2]. 2. Prioritize Inputs in Logic: Modify your workflow logic to prioritize the user-supplied input, falling back to github.ref_name only if the input is empty [1][2]. For example: ${{ github.event.inputs.tag || github.ref_name }} Regarding the zed-extension-action, it is designed to automate the bumping of Zed extensions [5]. When used with workflow_dispatch or automated triggers, ensure that the tag context is correctly handled. If the action's automatic detection of the "currently pushed tag" fails because the workflow_dispatch context does not provide a tag, you should explicitly pass the version or tag via the tag parameter provided by the action [5]: - uses: huacnlee/zed-extension-action@v2 with: extension-name: your-extension-name tag: ${{ github.event.inputs.tag || github.ref_name }} This approach ensures that your workflow remains robust whether triggered by a tag push (where github.ref_name is the tag) or a manual dispatch (where the tag must be provided via inputs) [1][2].

Citations:

🌐 Web query:

github actions workflow runs triggered by workflow_dispatch on branch or tag context ref_name

💡 Result:

When you manually trigger a workflow using the workflow_dispatch event in the GitHub UI, you are prompted to select a branch or tag from a dropdown menu [1]. This selection determines the context in which the workflow runs [2][3]. Regarding the context variables: 1. github.ref_name: This variable reflects the name of the branch or tag you selected in the UI [2][4]. If you select a branch, it will be the branch name (e.g., main); if you select a tag, it will be the tag name (e.g., v1.0.0) [2][4]. 2. github.ref: This contains the fully-formed reference [2][4]. If you selected a branch, it will be refs/heads/<branch_name>; if you selected a tag, it will be refs/tags/<tag_name> [2][4]. 3. github.ref_type: This will explicitly return either branch or tag, depending on what was selected [2][4]. It is important to note that when a workflow is triggered via workflow_dispatch, github.ref_name and related variables are always populated because the event requires you to target a specific reference (branch or tag) [3][1]. Common Pitfall: Users sometimes confuse the branch they selected in the workflow_dispatch UI with the default branch of the repository. Because workflow_dispatch requires the workflow file to exist on the default branch to be visible/triggerable [3][1], the workflow file itself always comes from the default branch, even if you are running it against the code of a different branch or tag. If your workflow logic relies on GITHUB_REF_NAME to identify a release or deployment target, it will return the name of the branch/tag you selected in the UI, not necessarily the branch where the workflow file resides [5]. If your use case requires specific versioning (like a tag), it is often safer to include a custom input field for the version/tag in your workflow_dispatch configuration rather than relying solely on the ref context [5][6].

Citations:

Guard the Zed publisher against branch-based manual dispatches.

This workflow allows manual execution, but workflow_dispatch runs against the selected branch unless a tag is chosen, and the action has no tag input. Add a required dispatch input or branch gate before publishing, or pass an explicit tag so the action does not attempt Zed publishing without a v* tag.

Source: MCP tools