mcu-debug / peripheral-viewer

Standalone Peripheral(SVD) Viewer extension extracted from cortex-debug, now works with any debugger
MIT License
10 stars 5 forks source link

Check marketplace keys #2

Open thegecko opened 1 year ago

thegecko commented 1 year ago

The CI System will make a release to the VS Code and OpenVSX marketplaces when main is tagged with a release.

These use the GitHub secrets:

Can these be added to the repository (or the org if they are used more widely)? I assume the VS Code one needs to come from @haneefdm as owner of the mcu-debug publisher, I can provide one for Open VSX if you don't have one.

haneefdm commented 1 year ago

Is this what triggers a marketplace release?

https://github.com/mcu-debug/svd-viewer/blob/eabf388e3983d9c0976631ce5da4982d907e6eee/.github/workflows/ci.yml#L56

That mean all tags? Not just a tag with a pattern?

Also, what version of vsce is used? vsce had failed on me twice in the last two years and it took me quite a bit of work to rollback and pick a version that worked.

thegecko commented 1 year ago

That mean all tags? Not just a tag with a pattern?

Yes, I only tag releases, but this can be made more specific.

Also, what version of vsce is used?

^2.6.4, keen to keep it updated.

vsce had failed on me twice in the last two years and it took me quite a bit of work to rollback and pick a version that worked.

I've had issues with yarn builds in the past (especially with monorepos), but since finding a reliable pattern I haven't seen any issues (my team and I maintain >10 extensions in this way).

haneefdm commented 1 year ago

My vsce problem was pretty unique. The latest version could not parse the package.json and errored out for no reason. It took them a week of scrambling to find a workaround first and make another release thereafter. For me,I had to roll back to a specific version. I did not want to wait for an vsce update once I found a workaround. It caused major havoc in the entire vscode extension community.

^2.6.4, keen to keep it updated.

Not sure that works because in your yarn.lock, it is set at 2.6.6 and it will not update unless the dependencies change or yarn.lock is deleted, running yarn upgrade, etc. For instance, latest vsce is 2.16.0 and when I ran yarn.install, it still remained at 2.6.6. I feel like yarn works a bit differently than npm in this regard.

Also, I never installed vsce via package.json. It had been globally installed. Your way is better.

haneefdm commented 1 year ago

I sometimes use the pre-release mechanism built into vsce and VSCode. I don't know if that is needed for something this simple, but on cortex-debug, it has been invaluable. If I have a need, I will create additional flows, I guess.

Following MS conventions, there are requirements for the sem-ver besides using a command-line option to mark vsix files as pre-release. Otherwise marketplace and VSCode get confused.

thegecko commented 1 year ago

Not sure that works because in your yarn.lock, it is set at 2.6.6

I update these manually in package.json if I need to and yarn sorts it out. There's even intellisense! An automated way would be to turn on dependabot. This is also another reason for the branch checks because dependabot package updates don't always work.

thegecko commented 1 year ago

Following MS conventions, there are requirements for the sem-ver besides using a command-line option to mark vsix files as pre-release.

Not quite, the main (non-prerelease) version will be picked if its a higher version than the prerelease, but not vice-versa. I think theres a recommendation to use odd/even to ensure they dont get muddled, but its messy.

I don't know if that is needed for something this simple, but on cortex-debug, it has been invaluable. If I have a need, I will create additional flows, I guess.

We've only ever done pre-release releases manually, but its possible to set up a workflow dispatch in the CI to create this flow if needed.

haneefdm commented 1 year ago

Not quite, the main (non-prerelease) version will be picked if its a higher version than the prerelease, but not vice-versa. I think theres a recommendation to use odd/even to ensure they dont get muddled, but its messy.

Yes, I know. Even that we got after two years of debating. The marketplace is run by a different team than vscode, marketplace folks refused to help as they did not see a need for Beta releases. The VSCode people eventually worked around marketplace issues, since they controlled both vsce and vscode extension UI.

haneefdm commented 1 year ago

I don't want to auto-publish anything. Until I am comfortable with it. I don't want to trust myself or Github

I disabled both vscode and open-vsx publishes in the workflow. I tried setting up open-vsx a few months ago and after going through multiple web pages, and account creations, I finally gave up. I don't have that kind of time. I will try later.

Lets make this stable in VSCode first.

thegecko commented 1 year ago

Theia- and vscodium-based solutions can't take advantage of this extension until it is on open-vsx. Sign up for an API key and use the ovsx command to publish, I found it quite simple.

haneefdm commented 1 year ago

Yes, your experience is different from mine. Mine was horrible and I gave up. But today it worked and I changed NOTHING. Used the old PAT I had generated 4 months ago.