Conversation
The npm publish workflow had no notification of any kind, so 0.1.2, 0.1.3 and 0.1.4 all reached npm silently — the DingTalk steps only ever existed in the OHPM SDK release. A build-time plugin ships less often than the SDK, which is exactly why nobody notices a release without being told. Mirrors the notification jobs in publish-ohpm.yml, including ignoreError so a broken webhook cannot mark a release that already reached npm as failed. On a tag the reported version is exact: the publish job already fails unless the tag matches hvigor-plugin/package.json. The DingTalk secrets are repository-level, so these jobs do not need the Production environment the publish job runs in.
An unassigned FLASHCAT_BUILD_DIR= in a pipeline reaches the option as '', which resolved to the module root. The sourcemap search walks recursively, so that collects every product's sourceMaps.map and uploads an arbitrary one under the current version — the same wrong-directory failure the product-aware default was added to prevent, reached through a different door. The warning for an empty key now names the apiKey option rather than only the environment variable, and points at --no-daemon, which is the likeliest reason the value arrived empty.
The demo wired symbol upload as fc-sdk-harmony-demo@0.1.0, but it reports RUM under flashcat-harmony-demo (DemoConfig's default, and what demo_config.json ships) at version 0.1.1 (AppScope versionName). ArkTS symbolication matches on service and version, so both keys were wrong and the demo could never validate symbolication end to end. Also document that hvigor-plugin/dist must be built before opening the project: entry/hvigorfile.ts imports it, hvigor evaluates that file on every invocation including DevEco project sync, and dist is not checked in.
The gate ran the upload task and asserted nothing. With -p product=default the probe's success and its fallback both resolve to build/default, and an upload failure never fails the build, so the step stayed green even if reading the product from the hvigor context was broken outright. It now requires the "(product 'default')" suffix in the scan line, which only the probe path emits.
Removing the enabled option is a breaking change, and 0.1.3 documented the dependency as ^0.1.3 — a range that picks up 0.1.4 automatically. Shipping it as a patch would have changed behaviour under everyone already on 0.1.x without them asking for it. 0.2.0 leaves that range where it is and makes the upgrade a deliberate step.
Removing it assumed that naming the task on the command line is an equivalent switch. It is not: in a pipeline, flipping a variable and editing the build command are not the same cost, and the second may need review. Consumers who want the upload off for one run reach for a variable, and hand-roll this gate when the plugin does not offer it. The defect was never that the option existed — it was that `enabled: false` returned without a word, which in a build log is indistinguishable from a successful upload. It now logs why it skipped.
With the enabled option kept, nothing here is breaking: the public type surface is a superset of 0.1.3 and every behaviour change is a fix to something that could not have worked. A patch release is the honest label, and consumers on ^0.1.3 pick it up as they should.
…tify Notify DingTalk when hvigor-plugin is published to npm
hvigor-plugin 0.1.5: fix task registration, build-dir resolution, and three review findings
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Brings main into the publish branch so the hvigor-plugin-v0.1.5 tag points at a commit the publish branch already contains, which the release workflow requires.
Includes the hvigor-plugin 0.1.5 changes (#37) and the npm publish DingTalk notification (#36).
Merge with a merge commit, not squash: squashing would rewrite the release commit and the tag validation would reject it.