I want to skip publish plugin, is that possible?

Issue

When utilizing the semantic-release package's pre-release functionality, the semantic-release-chrome's chrome web api call throws a version format error.

This is preventing me from publishing a new version of my chrome extension to a staging extension while maintaining the pre-release functionality on my develop branch.

• I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

• semantic-release-chrome version: 3.2.0
• node version: 18.11.15
• npm (or yarn) version: 3.3.0

What you did and problem description

My develop branch was set up as a pre-release branch in the semantic-release release.config. The semantic-release-chrome plugin was also configured within the release.config. I triggered the CD pipeline which resulted in a pre-release version name (such as 1.0.0-develop.1) to be passed to the semantic-release-chrome plugin. This version caused a chrome web store error due to the invalid semantic version format.

What happened

I do not have access to the exact error message at this point. It was something along the lines of an invalid version format error.

Reproduction repository/CodeSandbox

Suggested solution

Add an optional boolean allowPrerelease field to the PluginConfig interface. When allowPrerelease is specified and set to true, the semantic version number is parsed from the given version string instead of using the raw string. For example, if 1.0.0-develop.1 is the given pre-release version, then 1.0.0 will be parsed and used for the chrome web store publishing purposes.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency @types/semantic-release to v17.2.4
• chore(deps): update dependency semantic-release to v19.0.5
• chore(deps): update babel monorepo (@babel/cli, @babel/core, @babel/preset-env)
• chore(deps): update dependency @types/node to v18.11.9
• chore(deps): update dependency eslint to v8.28.0
• chore(deps): update dependency typescript to v4.9.3
• chore(deps): update typescript-eslint monorepo to v5.43.0 (@typescript-eslint/eslint-plugin, @typescript-eslint/parser)
• Click on this checkbox to rebase all open PRs at once

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

I've been trying to use this plugin to publish an extension to the Chrome Webstore, and haven't had a successful run yet. I have followed the Authentication instructions in the README, setting the variables in the Travis CI settings page, and have configured Travis to run semantic-release after tests pass on master.

Repo
Travis Build
Chrome Webstore Link - first version submitted manually

Not really sure what else might help here. If you need any other info please let me know. I think this is a really cool plugin for semantic-release, and when paired with semantic-release-firefox presents an awesome opportunity to make developing browser extensions that are built using the WebExtensions APIs easier.

Hello,

Is it possible to only prepare the zip file with an artifact in gitlab without publishing to Chrome? If so, how can I disable the publish job?

Thank you for your help!

I'm wondering if you have plans to support multiple release branches (which is currently in semantic-release beta) and what that might look like? I've currently patched my own fork but I'm not convinced it's the best approach. I'll create a PR so we can discuss the approach.

after running the task the extension got updated but the release is showing the following error in console

[3:33:41 PM] [semantic-release] › ✖  An error occurred while running semantic-release: { TypeError: Cannot read property '0' of undefined
    at publish (***extension/node_modules/semantic-release-chrome/dist/publish.js:60:44)
    at process._tickCallback (internal/process/next_tick.js:68:7) pluginName: 'semantic-release-chrome' }
{ TypeError: Cannot read property '0' of undefined
    at publish (***extension/node_modules/semantic-release-chrome/dist/publish.js:60:44)
    at process._tickCallback (internal/process/next_tick.js:68:7) pluginName: 'semantic-release-chrome' }

the this is my extension is a devtool extension with the permision 'activeTab' and therfor every release need a review maybe this has something to do with it

FR: Define some common lodash templates for asset namin

• I have searched the issues of this repository and believe that this is not a duplicate.

What you did and problem description

I would like to include version number in my zip file asset (since it will also be published to github) but depending on the environment that's not easy to do. (ex extensionname_v1.1.1.zip

What happened

Right now it doesn't support templating so I got extensionname_${nextRelease.version}.zip as the file name.

Suggested solution

I think supporting lodash templates like many of the other semantic relaese plugins should be easy enough:
Here's an example from git plugin: https://github.com/semantic-release/git/blob/11ef559f896fa110dfe9606cfab52e0b47ed48b4/lib/prepare.js#L65

Issue

• I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

• semantic-release-chrome version: https://github.com/exKAZUu/semantic-release-chrome (v1.1.1 with #44)
• node version: v10.16.3
• yarn version: 1.17.3

What you did and problem description

When publishing my extension (https://github.com/WillBooster/plantuml-visualizer/), PUBLISHED_WITH_FRICTION_WARNING occurs and it makes semantic-release-chrome fail.

What happened

Here is the log.

[1:55:45 PM] [semantic-release] › ℹ  Start step "publish" of plugin "semantic-release-chrome"
[1:55:54 PM] [semantic-release] › ✖  Failed step "publish" of plugin "semantic-release-chrome"
[1:55:54 PM] [semantic-release] › ℹ  Start step "fail" of plugin "@semantic-release/github"
[1:55:55 PM] [semantic-release] [@semantic-release/github] › ℹ  Created issue #229: https://github.com/WillBooster/plantuml-visualizer/issues/229.
[1:55:55 PM] [semantic-release] › ✔  Completed step "fail" of plugin "@semantic-release/github"
[1:55:55 PM] [semantic-release] › ✖  PUBLISHED_WITH_FRICTION_WARNING Your item needs extra time to review because your item has all hosts permission.
{ AggregateError: 
    SemanticReleaseError: Your item needs extra time to review because your item has all hosts permission.
        at publish (/home/circleci/project/node_modules/semantic-release-chrome/dist/publish.js:62:19)
    at publish (/home/circleci/project/node_modules/semantic-release-chrome/dist/publish.js:66:11)
    at process._tickCallback (internal/process/next_tick.js:68:7) name: 'AggregateError' }error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Reproduction repository/CodeSandbox

https://github.com/WillBooster/plantuml-visualizer/

Suggested solution

semantic-release-chrome should just ignore PUBLISHED_WITH_FRICTION_WARNING because this warning is not problematic for releasing extensions.

A hopefully simple question about the refresh token. If I understand correctly, a refresh token can expire, but can be used to obtain a new refresh token. I'm concerned that when the refresh token expires, the deploy process will fail in my Github Action because the action isn't able to update the refresh token that I'm storing in my repo's secrets. Is this a valid concern? If yes, how should I handle this?

Issue

• I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

Github Action

• semantic-release-chrome version: 3.2.0
• node version: v2.0
• npm (or yarn) version: 4.1.1

Relevant code or config

name: Release
on:
  push:
    branches:
      - main

permissions:
  contents: read # for checkout
env:
  GOOGLE_CLIENT_ID: ${{secrets.GOOGLE_CLIENT_ID}}
  GOOGLE_CLIENT_SECRET: ${{secrets.GOOGLE_CLIENT_SECRET}}
  GOOGLE_REFRESH_TOKEN: ${{secrets.GOOGLE_REFRESH_TOKEN}}
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
jobs:
  release:
    name: Release
    runs-on: ubuntu-latest
    permissions:
      contents: write # to be able to publish a GitHub release
      issues: write # to be able to comment on released issues
      pull-requests: write # to be able to comment on released pull requests
      id-token: write # to enable use of OIDC for npm provenance
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Enable Corepack before setting up Node
        run: corepack enable
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "20.x"
          cache: 'yarn'
      - name: Install dependencies
        run: yarn install --immutable
      - run: yarn build
      - run: yarn test
      - name: Verify the integrity of provenance attestations and registry signatures for installed dependencies
        run: yarn npm audit
      - name: Release
        run: npx semantic-release

Issue

• I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

• semantic-release-chrome version: 1.1.3

What you did and problem description

I've added semantic-release-chrome to a standard chrome extension package which has various source files that get compiled to a /dist folder via an npm build script.

My goal was to have semantic-release-chrome modify the manifest.json with the new version and then have that commited along with package.json and CHANGELOG.md as part of the final release commit.

What happened

Only the dist folder manifest.json is updated which means CWS will get the new version but not GitHub

Suggested solution

Maybe take an array of paths to update the manifest?
This is a bit tricky since updating and zipping both happen during the prepare step which means there's no chance for another plugin to do anything in beween.

Right now, my work around will be to copy the manifest from dest back to src folder in an exec plugin that comes later.

Issue

• I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

• semantic-release-chrome version:
• node version: 0.0.0-development
• npm (or yarn) version: Yarn 1.21.1

Feature proposal

Problem with the current Chrome Web Store is that the extension get's into a pending review state. In this state you cannot upload new versions. I propose to add a new target 'draft', which omits the publishing step, so only uploads the extension archive.

Branch is already implemented. The implementation is pretty straight-forward.

Issue

• I have searched the issues of this repository and believe that this is not a duplicate.

Your Environment

• semantic-release-chrome version: 1.1.3
• node version: 16.6.1
• npm version: 7.20.3

Relevant code or config

  "release": {
    "branches": [
      "main"
    ],
    "plugins": [
      "@semantic-release/release-notes-generator",
      [
        "semantic-release-chrome",
        {
          "asset": "asset.zip",
          "extensionId": "XXX"
        }
      ],
      [
        "@semantic-release/github",
        {
          "assets": [
            "asset.zip"
          ]
        }
      ]
    ]
  },

What you did and problem description

Running with above configuration results in the following error, failing the rest of the release steps:

Invalid package. Please make sure it is a valid zip file and the file manifest.json is at the root directory of the zip package.

Upon further inspection, it seems like the archived asset file contains the entire working directory instead of just the dist folder contents.

Theory: It seems like the path resolution points to a non-existent folder, and the archiver falls back to current folder.

What happened

[6:02:33 AM] [semantic-release] › ✖  PKG_INVALID_ZIP Invalid package. Please make sure it is a valid zip file and the file manifest.json is at the root directory of the zip package.
AggregateError: 
    SemanticReleaseError: Invalid package. Please make sure it is a valid zip file and the file manifest.json is at the root directory of the zip package.
        at /home/runner/work/xx/xx/node_modules/semantic-release-chrome/dist/publish.js:52:29
        at Array.forEach (<anonymous>)
        at publish (/home/runner/work/xx/xx/node_modules/semantic-release-chrome/dist/publish.js:51:25)
        at runMicrotasks (<anonymous>)
        at async validator (/home/runner/work/xx/xx/node_modules/semantic-release/lib/plugins/normalize.js:34:24)
        at async /home/runner/work/xx/xx/node_modules/semantic-release/lib/plugins/pipeline.js:37:34
        at async Promise.all (index 0)
        at async next (/home/runner/work/xx/xx/node_modules/p-reduce/index.js:16:18)
    at publish (/home/runner/work/xx/xx/node_modules/semantic-release-chrome/dist/publish.js:55:11)
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)
    at async validator (/home/runner/work/xx/xx/node_modules/semantic-release/lib/plugins/normalize.js:34:24)
    at async /home/runner/work/xx/xx/node_modules/semantic-release/lib/plugins/pipeline.js:37:34
    at async Promise.all (index 0)
    at async next (/home/runner/work/xx/xx/node_modules/p-reduce/index.js:16:18)

• archived asset file contains the entire working directory instead of just the dist folder contents.

Suggested solution

• Fix path resolution for the archive step to deflate the correct folder.

🚨 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:

• Usage documentation
• Frequently Asked Questions
• Support channels

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 📦🚀

Issue

• I have searched the issues of this repository and believe that this is not a duplicate.

What you did and problem description

I'm sometimes seeing a generic 400 Bad Request error like this:

[12:27:16 PM] [semantic-release] › ✖  An error occurred while running semantic-release: ErrorClass [HTTPError]: Response code 400 (Bad Request)
    at /home/runner/work/svg-screenshots/svg-screenshots/node_modules/got/index.js:123:13
    at processTicksAndRejections (node:internal/process/task_queues:93:5) {
  host: 'www.googleapis.com',
  hostname: 'www.googleapis.com',
  method: 'POST',
  path: '/chromewebstore/v1.1/items/nfakpcpmhhilkdpphcjgnokknpbpdllg/publish?publishTarget=default',
  statusCode: 400,
  statusMessage: 'Bad Request',
  pluginName: 'semantic-release-chrome'
}
ErrorClass [HTTPError]: Response code 400 (Bad Request)
    at /home/runner/work/svg-screenshots/svg-screenshots/node_modules/got/index.js:123:13
    at processTicksAndRejections (node:internal/process/task_queues:93:5) {
  host: 'www.googleapis.com',
  hostname: 'www.googleapis.com',
  method: 'POST',
  path: '/chromewebstore/v1.1/items/nfakpcpmhhilkdpphcjgnokknpbpdllg/publish?publishTarget=default',
  statusCode: 400,
  statusMessage: 'Bad Request',
  pluginName: 'semantic-release-chrome'
}

The last time I had this I figured I needed to update some things on the listing, but this time nothing is there.
It looks like others have run into this issue before too: #7

Suggested solution

Is there any way the plugin could provide a better error message with more details? It looks like it currently just gives us the HTTP status code, but I would bet there is some more detail in the response body that is being omitted.

Hello, script from a step 22 from https://github.com/GabrielDuarteM/semantic-release-chrome/blob/master/Authentication.md fails with an error:

16:46:24.481 Content Security Policy: The page’s settings blocked the loading of a resource at https://accounts.google.com/o/oauth2/token (“default-src”). debugger eval code:9:25
16:46:24.482
Promise { <state>: "rejected", <reason>: TypeError }

16:46:24.483
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.
    <anonymous> debugger eval code:9
    <anonymous> debugger eval code:39
[debugger eval code:9:26](chrome://devtools/content/webconsole/debugger%20eval%20code)
    <anonymous> debugger eval code:36
    AsyncFunctionThrow self-hosted:811
    (Async: async)
    <anonymous> debugger eval code:39
    getEvalResult resource://devtools/server/actors/webconsole/eval-with-debugger.js:242
    evalWithDebugger resource://devtools/server/actors/webconsole/eval-with-debugger.js:166
    evaluateJS resource://devtools/server/actors/webconsole.js:1131
    evaluateJSAsync resource://devtools/server/actors/webconsole.js:1022
    makeInfallible resource://devtools/shared/ThreadSafeDevToolsUtils.js:103

Issue

• I have searched the issues of this repository and believe that this is not a duplicate.

Problem

There's a vulnerability in got (GHSA-pfrx-2q88-qq97) which can be fixed by targeting a newer version of chrome-webstore-upload.

Suggested solution

I think we could tell renovate to update to 1.0.0; it should not have any breaking changes that affect this package.