GithubHelp home page GithubHelp logo

felipecrs / semantic-release-vsce Goto Github PK

View Code? Open in Web Editor NEW
34.0 1.0 11.0 4.18 MB

semantic-release plugin to package and publish VS Code extensions

License: MIT License

JavaScript 100.00%
vsce semantic-release-plugin semantic-release vscode hacktoberfest

semantic-release-vsce's Introduction

semantic-release-vsce

semantic-release plugin to package and publish VS Code extensions.

npm downloads ci dependencies peerDependencies semantic-release

Step Description
verify Verify the package.json and the validity of the personal access tokens against Visual Studio Marketplace and/or Open VSX Registry when publish is enabled
prepare Generate the .vsix file using vsce (can be be controlled by the packageVsix config option
publish Publish the extension to Visual Studio Marketplace and/or Open VSX Registry (learn more here)

Install

npm install --save-dev semantic-release-vsce

or

yarn add --dev semantic-release-vsce

Usage

The plugin can be configured in the semantic-release configuration file:

{
  "plugins": [
    "@semantic-release/commit-analyzer",
    "@semantic-release/release-notes-generator",
    [
      "semantic-release-vsce",
      {
        "packageVsix": true
      }
    ],
    [
      "@semantic-release/github",
      {
        "assets": [
          {
            "path": "*.vsix"
          }
        ]
      }
    ]
  ]
}

Configuration

packageVsix

Whether to package or not the extension into a .vsix file, or where to place it. This controls if vsce package gets called or not, and what value will be used for vsce package --out.

Value Description
"auto" (default) behave as true in case publish is disabled or the OVSX_PAT environment variable is present
true package the extension .vsix, and place it at the current working directory
false disables packaging the extension .vsix entirely
a string package the extension .vsix and place it at the specified path

publish

Whether to publish or not the extension to Visual Studio Marketplace and/or to Open VSX Registry. This controls if vsce publish or ovsx publish gets called or not. Learn more here.

Value Description
true (default) publishes the extension to Visual Studio Marketplace and/or to Open VSX Registry
false disables publishing the extension to Visual Studio Marketplace and/or to Open VSX Registry

publishPackagePath

Which .vsix file (or files) to publish. This controls what value will be used for vsce publish --packagePath.

Value Description
"auto" (default) uses the .vsix packaged during the prepare step (if packaged), or behave as false otherwise
false do not use a .vsix file to publish, which causes vsce to package the extension as part of the publish process
a string publish the specified .vsix file(s). This can be a glob pattern, or a comma-separated list of files

packageRoot

The directory of the extension relative to the current working directory. Defaults to cwd.

Environment variables

The following environment variables are supported by this plugin:

Variable Description
OVSX_PAT Optional. The personal access token to push to Open VSX Registry
VSCE_PAT Optional. The personal access token to publish to Visual Studio Marketplace
VSCE_TARGET Optional. The target to use when packaging or publishing the extension (used as vsce package --target ${VSCE_TARGET}). When set to universal, behave as if VSCE_TARGET was not set (i.e. build the universal/generic vsix). See the platform-specific example

Configuring vsce

You can set vsce options in the package.json, like:

{
  "vsce": {
    "baseImagesUrl": "https://my.custom/base/images/url",
    "dependencies": true,
    "yarn": false
  }
}

For more information, check the vsce docs.

Publishing

This plugin can publish extensions to Visual Studio Marketplace and/or Open VSX Registry.

You can enable or disable publishing with the publish config option.

When publish is enabled (default), the plugin will publish to Visual Studio Marketplace if the VSCE_PAT environment variable is present, and/or to Open VSX Registry if the OVSX_PAT environment variable is present.

For example, you may want to disable publishing if you only want to publish the .vsix file as a GitHub release asset.

Publishing to Visual Studio Marketplace

Publishing extensions to Visual Studio Marketplace using this plugin is easy:

  1. Create your personal access token for Visual Studio Marketplace. Learn more here.

  2. Configure the VSCE_PAT environment variable in your CI with the token that you created.

  3. Enjoy! The plugin will automatically detect the environment variable and it will publish to Visual Studio Marketplace, no additional configuration is needed.

Publishing to Open VSX Registry

Publishing extensions to Open VSX Registry using this plugin is easy:

  1. Create your personal access token for Open VSX Registry. Learn more here.

  2. Configure the OVSX_PAT environment variable in your CI with the token that you created.

  3. Enjoy! The plugin will automatically detect the environment variable and it will publish to Open VSX Registry, no additional configuration is needed.

Examples

GitHub Actions

name: release

on:
  push:
    branches: [master]

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: 16
      - run: npm ci
      - run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # In case you want to publish to Visual Studio Marketplace
          VSCE_PAT: ${{ secrets.VSCE_PAT }}
          # In case you want to publish to Open VSX Registry
          OVSX_PAT: ${{ secrets.OVSX_PAT }}

Platform-specific on GitHub Actions

  1. Install semantic-release-stop-before-publish

    npm install --save-dev semantic-release-stop-before-publish

    We will use it to make semantic-release stop before publishing anything, so that we can use semantic-release to build each .vsix in a matrix.

  2. Separate your semantic-release configuration into two, one for packaging and another for publishing.

    The one for packaging has semantic-release-stop-before-publish so that semantic-release does not publish anything (which includes the git tag).

    // package.release.config.js
    module.exports = {
      plugins: [
        '@semantic-release/commit-analyzer',
        '@semantic-release/release-notes-generator',
        [
          'semantic-release-vsce',
          {
            packageVsix: true,
            publish: false, // no-op since we use semantic-release-stop-before-publish
          },
        ],
        'semantic-release-stop-before-publish',
      ],
    };

    The one for publishing does not package the .vsix, but publishes all the *.vsix files.

    // publish.release.config.js
    module.exports = {
      plugins: [
        '@semantic-release/commit-analyzer',
        '@semantic-release/release-notes-generator',
        [
          'semantic-release-vsce',
          {
            packageVsix: false,
            publishPackagePath: '*/*.vsix',
          },
        ],
        [
          '@semantic-release/github',
          {
            assets: '*/*.vsix',
          },
        ],
      ],
    };

    Note: do not forget to remove your existing semantic-release configuration.

  3. Create a workflow file like below:

# .github/workflows/ci.yaml
name: ci

on:
  push:
    branches: [master]

jobs:
  build:
    strategy:
      matrix:
        include:
          - os: windows-latest
            target: win32-x64
            npm_config_arch: x64
          - os: windows-latest
            target: win32-ia32
            npm_config_arch: ia32
          - os: windows-latest
            target: win32-arm64
            npm_config_arch: arm
          - os: ubuntu-latest
            target: linux-x64
            npm_config_arch: x64
          - os: ubuntu-latest
            target: linux-arm64
            npm_config_arch: arm64
          - os: ubuntu-latest
            target: linux-armhf
            npm_config_arch: arm
          - os: ubuntu-latest
            target: alpine-x64
            npm_config_arch: x64
          - os: macos-latest
            target: darwin-x64
            npm_config_arch: x64
          - os: macos-latest
            target: darwin-arm64
            npm_config_arch: arm64
          - os: ubuntu-latest
            target: universal
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-node@v3
        with:
          node-version: 16

      - if: matrix.target != 'universal'
        name: Install dependencies (with binaries)
        run: npm ci
        env:
          npm_config_arch: ${{ matrix.npm_config_arch }}

      - if: matrix.target == 'universal'
        name: Install dependencies (without binaries)
        run: npm ci

      - run: npx semantic-release --extends ./package.release.config.js
        env:
          VSCE_TARGET: ${{ matrix.target }}
          # All tokens are required since semantic-release needs to validate them
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # In case you want to publish to Visual Studio Marketplace
          VSCE_PAT: ${{ secrets.VSCE_PAT }}
          # In case you want to publish to Open VSX Registry
          OVSX_PAT: ${{ secrets.OVSX_PAT }}

      - uses: actions/upload-artifact@v3
        with:
          name: ${{ matrix.target }}
          path: '*.vsix'

  release:
    runs-on: ubuntu-latest
    needs: build
    steps:
      - uses: actions/checkout@v3

      - uses: actions/setup-node@v3
        with:
          node-version: 16

      - run: npm ci

      - uses: actions/download-artifact@v3

      - run: npx semantic-release --extends ./publish.release.config.js
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # In case you want to publish to Visual Studio Marketplace
          VSCE_PAT: ${{ secrets.VSCE_PAT }}
          # In case you want to publish to Open VSX Registry
          OVSX_PAT: ${{ secrets.OVSX_PAT }}

A reference implementation can also be found in the VS Code ShellCheck extension.

semantic-release-vsce's People

Contributors

andrewleedham avatar dankeboy36 avatar dependabot[bot] avatar ewanharris avatar felipecrs avatar felixfbecker avatar greenkeeper[bot] avatar johnstoncode avatar killdozerx2 avatar nhedger avatar simonsiefke avatar tastefulelk avatar wingrunr21 avatar wkillerud avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar

semantic-release-vsce's Issues

Action required: Greenkeeper could not be activated 🚨

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Check that access token is still valid in verify step

I had a publish fail because my personal access token was expired. However, the verifyConditions step of semantic-release-vsce passed so semantic-release ended up creating and pushing the git tag, meaning on the next CI build it mistakenly thought various commits had been published, when they hadn't.

The npm plugin verifies the npm token in the verifyConditions step in most cases: https://github.com/semantic-release/npm/blob/master/index.js#L36

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.


The release 5.2.2 on branch master cannot be published as it is out of range.

Based on the releases published on other branches, only versions within the range >=5.2.1 <5.2.2 can be published from branch master.

The following commits are responsible for the invalid release:

  • build(deps): bump ovsx from 0.5.1 to 0.5.2 (#347) (5c94e27)
  • fix: use context's cwd for vsce calls (#349) (86b499e)
  • fix: make sure to use locally installed vsce (#348) (6d18e32)
  • build(deps-dev): bump @commitlint/cli from 17.1.2 to 17.2.0 (#352) (5f949bb)
  • build(deps-dev): bump @commitlint/config-conventional (#351) (f8b16d1)
  • build(deps-dev): bump eslint-plugin-n from 15.3.0 to 15.4.0 (#350) (a56f765)
  • build(deps-dev): bump ava from 4.3.3 to 5.0.1 (#345) (c17e38e)
  • build(deps-dev): bump eslint from 8.25.0 to 8.26.0 (#346) (e469aa8)

Those commits should be moved to a valid branch with git merge or git cherry-pick and removed from branch master with git revert or git reset.

A valid branch could be next.

See the workflow configuration documentation for more details.


Good luck with your project ✨

Your semantic-release bot 📦🚀

Change VSCE_PAT to VSCE_TOKEN

All the other env vars GH_TOKEN, NPM_TOKEN etc use the TOKEN suffix (and all my semantically released vscode extensions 😛 )

Not working with `@cycjimmy/semantic-release-action`

When the semantic release action is executed using the vsce plugin in my repo, Testify, i get the following error:

[8:23:46 PM] [semantic-release] › ✖  EINVALIDVSCETOKEN Invalid vsce token. Additional information:

Error: Command failed with ENOENT: vsce verify-pat
spawn vsce ENOENT
Error: AggregateError: 
    SemanticReleaseError: Invalid vsce token. Additional information:
    Error: Command failed with ENOENT: vsce verify-pat
    spawn vsce ENOENT
        at module.exports (/home/runner/work/_actions/cycjimmy/semantic-release-action/v3/node_modules/semantic-release-vsce/lib/verify-auth.js:14:11)
        at processTicksAndRejections (node:internal/process/task_queues:96:5)
        at async module.exports (/home/runner/work/_actions/cycjimmy/semantic-release-action/v3/node_modules/semantic-release-vsce/lib/verify.js:8:3)
        at async verifyConditions (/home/runner/work/_actions/cycjimmy/semantic-release-action/v3/node_modules/semantic-release-vsce/index.js:10:3)
        at async validator (/home/runner/work/_actions/cycjimmy/semantic-release-action/v3/node_modules/semantic-release/lib/plugins/normalize.js:34:24)
        at async /home/runner/work/_actions/cycjimmy/semantic-release-action/v3/node_modules/semantic-release/lib/plugins/pipeline.js:37:34
        at async Promise.all (index 0)
        at async next (/home/runner/work/_actions/cycjimmy/semantic-release-action/v3/node_modules/p-reduce/index.js:16:18)

I am using the GitHub secrets to store my Personal Access Token and I double checked that the token is really there.

I also double checked the permissions of said token in the Azure Portal and it has the necessary access specified in the VSCode documentation

When I run the same command as the plugin locally, I get the following result:

The Personal Access Token verification succeeded for the publisher 'felixjb'.

Is this a bug? Am I doing anything wrong?

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.


The release 5.0.0 on branch master cannot be published as it is out of range.

Based on the releases published on other branches, only versions within the range >=4.0.1 <5.0.0 can be published from branch master.

The following commits are responsible for the invalid release:

  • refactor!: drop support for VSCE_TOKEN (#234) (4fbaa86)
  • refactor!: drop yarn option (#233) (df92b55)
  • build(deps-dev): bump semantic-release from v18 to v19 (#232) (8fece4f)
  • build(deps-dev): upgrade eslint to v8 (#231) (ca721ee)
  • build(deps): bump vsce from 1.99.0 to 2.6.3 (#225) (2dbf345)
  • build(deps-dev): bump eslint-plugin-promise from 5.1.0 to 6.0.0 (#216) (577f9fd)
  • build(deps): set minimum semantic-release as 18 (#210) (50e9a8e)
  • build(deps): bump @semantic-release/error from 2.2.0 to 3.0.0 (#183) (0b91510)
  • build(deps-dev): bump conventional-changelog-conventionalcommits (#221) (dcef06d)
  • build(deps-dev): bump husky from 6.0.0 to 7.0.4 (#193) (b1da469)
  • build(deps-dev): bump sinon from 11.1.2 to 12.0.1 (#201) (31c3397)
  • build(deps-dev): bump @commitlint/config-conventional (#217) (f352672)
  • build(deps-dev): bump eslint-plugin-import from 2.23.4 to 2.25.4 (#224) (8cab41b)
  • build(deps-dev): bump @commitlint/cli from 12.1.4 to 16.0.2 (#227) (ee537ff)
  • build(deps-dev): bump ava from 3.15.0 to 4.0.1 (#228) (4684482)
  • build(deps-dev): remove eslint-plugin-standard (#230) (ebd489a)
  • build(deps): drop support for Node 10 and 12 (#229) (dc6424c)
  • ci: set dependabot branch as next (f370dfe)
  • ci: enable next branch (3dda24d)

Those commits should be moved to a valid branch with git merge or git cherry-pick and removed from branch master with git revert or git reset.

A valid branch could be next.

See the workflow configuration documentation for more details.


Good luck with your project ✨

Your semantic-release bot 📦🚀

Allow not to publish the extension

Hey 👋,

It would be great if we could use this plugin without the need to publish the extension to the marketplace.

I could send in a PR to that effect if you're open to it.

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.


Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two Factor Authentication for your account, set its level to "Authorization only" in your account settings. semantic-release cannot publish with the default "
Authorization and writes" level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.


Good luck with your project ✨

Your semantic-release bot 📦🚀

Will this project going to be maintained?

I'm about to create a fork of it because I need to add more features to this plugin to use it.

However, it's always good to prevent unneeded forks so people do not get confused.

If you're looking for maintainers, I'm also willing to help.

/cc @raix @felixfbecker

Bug semantic-release v12 does break your plugin

Hi There

First of all: Cool!

I just want to check if I do something wrong:

[Semantic release]: An error occurred while running semantic-release: Error: The "getLastRelease" plugin output if defined, must be an object with a valid semver version in the "version" property and the corresponding git reference in "gitHead" property. Received: { version: '1.8.0' }
    at Object.getLastRelease (/home/travis/build/buehler/typescript-hero/node_modules/semantic-release/lib/plugins/normalize.js:44:13)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:160:7)

That's the output of SR when I run it with version 12.

Is there something missing?

(package.json):

"release": {
    "verifyConditions": [
      "semantic-release-vsce",
      "@semantic-release/github"
    ],
    "getLastRelease": "semantic-release-vsce",
    "publish": [
      {
        "path": "semantic-release-vsce",
        "packageVsix": "your-extension.vsix"
      },
      {
        "path": "@semantic-release/github",
        "assets": "your-extension.vsix"
      }
    ]
  },

Cheers

Rewrite docs following the other semantic-release plugins

It would be good if the docs had a similar template as the other semantic-release plugins, such as @semantic-release/github. This would make it easier for newcomers to understand.

Also, the example in the docs uses an older version of semantic-release, where you had to set which plugins to use at each step. Nowadays, you can do this simpler, by only specifying which plugins to use.

Setting package root

Hi,

I've a github project that is pushing multiple packages (npm, vsce, etc...)
Each are built to an out folder with custom package.json

For npm, I define the path as:

    [
      "@semantic-release/npm",
      {
        "pkgRoot": "./out/linter"
      }
    ],

But I cannot find a similar setting for vsce, which result in the plugin publishing the root sources instead of out/vscode, which basically publishes an unusable package.

I wonder how can that be done using this plugin?

An in-range update of vsce is breaking the build 🚨

The dependency vsce was updated from 1.58.0 to 1.59.0.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

vsce is a direct dependency of this project, and it is very likely causing it to break. If other packages depend on yours, this update is probably also breaking those in turn.

Status Details
  • continuous-integration/travis-ci/push: The Travis CI build failed (Details).

Commits

The new version differs by 3 commits.

See the full diff

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.


Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.


Good luck with your project ✨

Your semantic-release bot 📦🚀

vsce verify-pat does not seem to use `publisher` from `package.json`

Log

pnpx vsce verify-pat scarf --pat $VSCE_PAT
The Personal Access Token verification succeeded for the publisher 'scarf'.

pnpx semantic-release
Error: Command failed with ENOENT: vsce verify-pat
spawn vsce ENOENT
AggregateError: 
    SemanticReleaseError: Invalid vsce token. Additional information:
    Error: Command failed with ENOENT: vsce verify-pat
    spawn vsce ENOENT

I've correctly set up publisher as scarf in my package.json, however it fails with an error.

Error using @semantic-release/git on the getLastRelease hook

As of @semantic-release/git v3.0.0 (semantic-release/git@c8119da), getLastRelease is no longer part of the @semantic-release/git plugin, so you if configure semantic-release-vsce as it is said in the readme, using "getLastRelease": "@semantic-release/git", semantic-release throws the following error: EPLUGINCONF The getLastRelease plugin must be a function, or an object with a function in the property getLastRelease.

Is there any way to continue using this plugin without having to downgrade @semantic-release/git to v2.2.0?

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you can benefit from your bug fixes and new features again.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can fix this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here are some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.


Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two Factor Authentication for your account, set its level to "Authorization only" in your account settings. semantic-release cannot publish with the default "
Authorization and writes" level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.


Good luck with your project ✨

Your semantic-release bot 📦🚀

Support additional params to package and publish

Hi, I'm using pnpm and there is a workaround needed: microsoft/vscode-vsce#421 (comment)

// this is my package.json
"scripts": {
    "package": "pnpm vsce package --no-dependencies",
    "publish": "pnpm vsce publish --no-dependencies"
}

Without it, the release fails with:

Error: Command failed: npm list --production --parseable --depth=99999 --loglevel=error
npm ERR! code ELSPROBLEMS

Version 10 of node.js has been released

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

  • Added the new Node.js version to your .travis.yml
  • The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

More information on this issue

Greenkeeper has checked the engines key in any package.json file, the .nvmrc file, and the .travis.yml file, if present.

  • engines was only updated if it defined a single version, not a range.
  • .nvmrc was updated to Node.js 10
  • .travis.yml was only changed if there was a root-level node_js that didn’t already include Node.js 10, such as node or lts/*. In this case, the new version was appended to the list. We didn’t touch job or matrix configurations because these tend to be quite specific and complex, and it’s difficult to infer what the intentions were.

For many simpler .travis.yml configurations, this PR should suffice as-is, but depending on what you’re doing it may require additional work or may not be applicable at all. We’re also aware that you may have good reasons to not update to Node.js 10, which is why this was sent as an issue and not a pull request. Feel free to delete it without comment, I’m a humble robot and won’t feel rejected 🤖


FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.


Your Greenkeeper Bot 🌴

Error at getLastRelease

[Semantic release]: Load plugin semantic-release-vsce
[Semantic release]: Load plugin @semantic-release/github
[Semantic release]: Load plugin semantic-release-vsce
[Semantic release]: Load plugin semantic-release-vsce
[Semantic release]: Load plugin @semantic-release/github
[Semantic release]: Run automated release for branch master
[Semantic release]: Call plugin verify-conditions
[Semantic release]: Verify authentication for vsce
[Semantic release]: Call plugin get-last-release
[Semantic release]: Lookup extension details for "felixfbecker.php-intellisense".
[Semantic release]: Found version [object Object] of package felixfbecker.php-intellisense
[Semantic release]: An error occurred while running semantic-release: Error: The "getLastRelease" plugin output if defined, must be an object with an optionnal valid semver version in the "version" property.. Received: { version: 
   { version: '2.0.1',
     flags: 'validated',
     lastUpdated: '2017-11-19T02:45:21.723Z' } }
    at Object.getLastRelease (/home/travis/build/felixfbecker/vscode-php-intellisense/node_modules/semantic-release/lib/plugins/normalize.js:30:13)
    at <anonymous>
    at process._tickCallback (internal/process/next_tick.js:188:7)

Reverted release v4.0.0

Thanks to @felixfbecker, it was identified that this breaking change was unnecessary. Therefore, the releases v4.0.0 and v4.0.1 were unpublished from NPM, and the release v3.1.3 is the current up-to-date.

For users

For those who already upgraded to v4, please downgrade it to v3.1.3. If you had set vsce in your devDependencies because it was a peerDependency on v4, you can now remove it.

If you intend to make this plugin use a specific version of vsce, you can manually add it to your devDependencies, as long as the version you choose matches the current range of supported versions, which today is ^1.73.0 (any 1.x version higher or equal than 1.83).

For maintainers

When a new breaking change finally arrives targeting v4.0.0 again, it will be needed to perform work around over semantic-release, since NPM does not support re-publishing the same version. Basically:

  1. Push the v4.0.0 and v4.0.1 tags to GitHub, pointing to the to-date latest tag
  2. Trigger semantic-release, so the next version will be v4.0.2
  3. Delete the tags v4.0.0 and v4.0.1 on GitHub
  4. Edit the release notes to fix the first line, pointing to the correct version comparison URL.

Run vsce package without --out

Then vsce automatically finds a filename for the file. Thus, we can use a wildcard to include *.vsix in GitHub Releases.

Support prereleases

I know VSC plugins don't support prereleases, but since it's recommended to use Github releases to handle regression errors, we could also use Github to handle beta releases.

It's very possible that I'm missing an obvious solution to this. 😅

No way to pass extra options to vsce

Due to master->main branch rename we need to pass --githubBranch option to vsce. I currently see no way of doing that and because of that relative image paths on VSCode Market place are broken.

Support package/publish arguments

Would it be possible to support CLI arguments, eg. something like:

      - name: Publish
        run: npx semantic-release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          VSCE_PAT: ${{ secrets.PUBLISHER_TOKEN }}
          VSCE_PACKAGE_ARGS: "--baseImagesUrl https://raw.githubusercontent.com/org/repo/branch/"

"HIGH" Vulnerability found in simple-get dependency

As I am building a Semantic Release image, pulling in this plugin, I am finding simple-get <= 4.0.1 vulnerabilty:

Using Trivy:

+------------+------------------+----------+-------------------+---------------+--------------------------------------+
|  LIBRARY   | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |                TITLE                 |
+------------+------------------+----------+-------------------+---------------+--------------------------------------+
| simple-get | CVE-2022-0355    | HIGH     | 3.1.0             | 4.0.1         | simple-get: exposure of sensitive    |
|            |                  |          |                   |               | information to an unauthorized actor |
|            |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2022-0355 |
+------------+------------------+----------+-------------------+---------------+--------------------------------------+

Using Grype:

NAME         INSTALLED  FIXED-IN  VULNERABILITY        SEVERITY 
simple-get   3.1.0      4.0.1     GHSA-wpg7-2c88-r8xv  High

Is this package still maintained?

Hello, Firstly thank you for creating this package i use it a lot. Are you planning on updating the deps? If not would you like help maintaining this package?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.