@automattic/vip 4.1.2 → 4.1.3
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/lib/edge-workers/toolchains/assemblyscript/constants.js +1 -1
- package/docs/EDGE-WORKERS.md +2 -2
- package/docs/NPM-RELEASE-RECOVERY.md +47 -0
- package/internal/edgeworkers/build_test.go +1 -1
- package/internal/edgeworkers/templates/edge-workers.json +1 -1
- package/internal/edgeworkers/templates/package.json +1 -1
- package/package.json +1 -1
|
@@ -9,6 +9,6 @@ exports.SDK_VERSION = exports.SDK_PACKAGE = exports.DEFAULT_ENTRY = exports.ASSE
|
|
|
9
9
|
*/
|
|
10
10
|
|
|
11
11
|
const SDK_PACKAGE = exports.SDK_PACKAGE = '@automattic/vip-edge-workers-sdk';
|
|
12
|
-
const SDK_VERSION = exports.SDK_VERSION = '0.
|
|
12
|
+
const SDK_VERSION = exports.SDK_VERSION = '0.5.0';
|
|
13
13
|
const ASSEMBLYSCRIPT_VERSION = exports.ASSEMBLYSCRIPT_VERSION = '0.27.0';
|
|
14
14
|
const DEFAULT_ENTRY = exports.DEFAULT_ENTRY = 'assembly/index.ts';
|
package/docs/EDGE-WORKERS.md
CHANGED
|
@@ -37,7 +37,7 @@ edge-workers/
|
|
|
37
37
|
```
|
|
38
38
|
|
|
39
39
|
`build/` is created when a worker is compiled and is ignored by Git. The generated direct
|
|
40
|
-
dependencies are exact: `@automattic/vip-edge-workers-sdk` is `0.
|
|
40
|
+
dependencies are exact: `@automattic/vip-edge-workers-sdk` is `0.5.0` and `assemblyscript` is
|
|
41
41
|
`0.27.0`. The starter exports only `alloc` and `on_client_response`; the other request phases are
|
|
42
42
|
commented examples and are not active WASM exports.
|
|
43
43
|
|
|
@@ -48,7 +48,7 @@ The project descriptor selects the toolchain for every worker in the project:
|
|
|
48
48
|
```json
|
|
49
49
|
{
|
|
50
50
|
"type": "assemblyscript",
|
|
51
|
-
"sdk": "@automattic/vip-edge-workers-sdk@0.
|
|
51
|
+
"sdk": "@automattic/vip-edge-workers-sdk@0.5.0"
|
|
52
52
|
}
|
|
53
53
|
```
|
|
54
54
|
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# Recover an interrupted stable npm release
|
|
2
|
+
|
|
3
|
+
Use this when the stable publishing workflow created a GitHub release and tag,
|
|
4
|
+
but failed before publishing that version to npm.
|
|
5
|
+
|
|
6
|
+
1. Ensure the recovery workflow is merged into `trunk`.
|
|
7
|
+
2. Open **Actions → Publish to npm (if applicable) → Run workflow**.
|
|
8
|
+
3. Select branch **trunk**, set **release_mode** to **recover-stable**, and enter
|
|
9
|
+
the existing tag in **release_version** (for example, `4.1.2`).
|
|
10
|
+
4. Leave **npm_tag** unchanged; stable recovery always publishes to `latest`.
|
|
11
|
+
5. Select **Run workflow** and inspect the **Recover stable release** job.
|
|
12
|
+
|
|
13
|
+
Do not rerun the original failed run to pick up workflow changes: reruns retain
|
|
14
|
+
the original workflow. The original action also tries to recreate the existing
|
|
15
|
+
GitHub release before it reaches npm publishing.
|
|
16
|
+
|
|
17
|
+
Recovery builds and tests the existing tag, preserves the GitHub release, and
|
|
18
|
+
uses the same workflow identity and `npm-publish` environment for npm trusted
|
|
19
|
+
publishing. It enables npm error logging and refuses versions already published
|
|
20
|
+
or older than the current `latest`. Successful publication starts the changelog
|
|
21
|
+
and command-reference documentation jobs.
|
|
22
|
+
|
|
23
|
+
Recovery does not create the next development-version PR that the regular
|
|
24
|
+
publishing action normally opens after publication. Handle that version bump
|
|
25
|
+
separately once recovery succeeds. If npm publication succeeds but a downstream
|
|
26
|
+
documentation job fails, rerun only the failed jobs.
|
|
27
|
+
|
|
28
|
+
## How the release artifact is prepared
|
|
29
|
+
|
|
30
|
+
Stable releases, prereleases and recovery use the local
|
|
31
|
+
[release tooling](../.github/scripts/npm-release/README.md) in this repository.
|
|
32
|
+
No `vip-actions` changes are required. After building and testing, it runs the
|
|
33
|
+
prepublish/pack preparation hooks in the source checkout and uses `rsync -a`
|
|
34
|
+
without `-H` to copy into a fresh staging directory. This turns native dependency
|
|
35
|
+
hard links into independent files without changing the source checkout's links. The workflow saves the current
|
|
36
|
+
release tools before checking out an old tag, so that tag need not contain the
|
|
37
|
+
new helper.
|
|
38
|
+
|
|
39
|
+
The helper packs with lifecycle scripts disabled, validates the archive and runs
|
|
40
|
+
`smoke:release` inside an extraction of that exact tarball. Validation rejects
|
|
41
|
+
links and unsafe archive entries and verifies the package name/version. Both
|
|
42
|
+
the dry run and real publication use the same validated `.tgz` with
|
|
43
|
+
`--ignore-scripts`, so another build cannot recreate hard links after validation.
|
|
44
|
+
|
|
45
|
+
For `4.1.2`, the Linux builds of bundled `cpu-features` and `ssh2` created three
|
|
46
|
+
hard links that npm rejected with `E415: Hard link is not allowed`. Staging fixes
|
|
47
|
+
the archive while preserving dependency bundling and the existing release tag.
|
|
@@ -16,7 +16,7 @@ func TestScaffoldDoesNotOverwriteOrInstall(t *testing.T) {
|
|
|
16
16
|
t.Fatal(err)
|
|
17
17
|
}
|
|
18
18
|
before, _ := os.ReadFile(filepath.Join(dir, "package.json"))
|
|
19
|
-
if !strings.Contains(string(before), `"0.
|
|
19
|
+
if !strings.Contains(string(before), `"0.5.0"`) || !strings.Contains(string(before), `"0.27.0"`) {
|
|
20
20
|
t.Fatalf("dependencies: %s", before)
|
|
21
21
|
}
|
|
22
22
|
if err := ScaffoldProject(dir, "assemblyscript"); err == nil {
|