Notify DingTalk when hvigor-plugin is published to npm - #36
Merged
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.
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
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.
0.1.2, 0.1.3 and 0.1.4 all reached npm without any notification:
publish-hvigor-plugin.ymlhas never had one. The DingTalk steps only ever existed inpublish-ohpm.yml, which is a separate workflow for the OHPM SDK packages and triggers on a different tag.A build-time plugin ships less often than the SDK, which is precisely why a silent release goes unnoticed.
What this adds
notify-successandnotify-failure, mirroring the jobs inpublish-ohpm.yml:ignoreError: "true", so a broken webhook cannot mark a release that already reached npm as failedhvigor-plugin/package.jsonenvironment: Productionon these jobs: the DingTalk secrets are repository-level, and only the publish job needs the environment gateWhere it has to live
A tag-triggered run uses the workflow file at the tagged commit, and release tags point at commits on
main— so this has to be onmainto take effect for the next release. Theworkflow_dispatchpath runs frompublish, which will pick it up the next timemainis merged there during a release.