Skip to content

Conversation

@stefanvanburen
Copy link
Member

(Building on #462, thanks @paul-sachs!)

This adds a publish workflow, which is triggered by publishing a release on this repo (similar to how the various protovalidate repositories work). The workflow takes the release's version, creates both a VS Code Marketplace release and OpenVSX release.

Completes #22.

(Building on #462, thanks @paul-sachs!)

This adds a publish workflow, which is triggered by publishing a release
on this repo (similar to how the various protovalidate repositories
work). The workflow takes the release's version, creates both a VS Code
Marketplace release and OpenVSX release.

Completes #22.
setup_only: true
- name: install-deps
run: make install
run: npm ci
Copy link
Member Author

Choose a reason for hiding this comment

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

seemed like we should use npm ci in CI, not npm install...

Comment on lines +32 to +33
git config user.name "${{ github.actor }}"
git config user.email "${{ github.actor }}@users.noreply.github.com"
Copy link
Member Author

Choose a reason for hiding this comment

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

I think we need this to do the git commit that will result below on vsce publish <version>, where the <version> comes from the release tag. (I'd like to try this in a pre-release, hence adding all of that duplicate machinery here.)

Comment on lines +50 to +52
- name: Push version commit
run: |
git push origin HEAD:${{ github.event.repository.default_branch }}
Copy link
Member Author

Choose a reason for hiding this comment

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

Likewise, I think after the action creates the commit, we should push the commit directly to HEAD (it'll just be bumping the "version" field in package.json to match the tag).

@stefanvanburen
Copy link
Member Author

@doriable, @paul-sachs - I think the only real way to test this publishing out is landing this PR and trying some pre-releases, which should give us some confidence that the regular tagging workflow will work.

I'd suggest we land this, tag a pre-release called 0.8.2-rc1 and see if the workflow works appropriately. Assuming that works and we like this approach, I'll add some documentation (RELEASE.md?) explaining how to do this for future maintainers.

@stefanvanburen stefanvanburen marked this pull request as ready for review January 15, 2026 20:59
@stefanvanburen stefanvanburen requested review from doriable and paul-sachs and removed request for paul-sachs January 15, 2026 20:59
@stefanvanburen
Copy link
Member Author

🤞 this works the first time when we try it out, but may need follow-ups to fix issues we run into.

@stefanvanburen stefanvanburen merged commit 4dc55b1 into main Jan 20, 2026
9 checks passed
@stefanvanburen stefanvanburen deleted the svanburen/publish-workflow branch January 20, 2026 15:10
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.

3 participants