[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6ACBNH0HSYFX2K9CYJSPAVM":3,"skill-same:01M6ACBNH0HSYFX2K9CYJSPAVM":61},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":43,"ownerHtmlUrl":44,"ownerBlogUrl":45,"ownerDescription":6,"updatedAt":46,"install":47,"resources":60},"01M6ACBNH0HSYFX2K9CYJSPAVM","package",null,"Rebuild the SkyWalking distribution and OAP Docker image after source changes. Use before running e2e tests so the image reflects your code changes. Avoids the \"image looks updated but runtime has stale jars\" trap.","apache\u002Fskywalking","apache","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47359?v=4","01M6AC83E6K4FDKK7HZ8WNMQKE","The Apache Software Foundation","01M6ACB19NRCBY51M74TPEM71Y",25001,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fpackage\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000011","运维与部署","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[5,27,28,29,30,31],"image","docker","e2e tests","code","skywalking","2026-11-10 10:12:30",false,"---\nname: package\ndescription: Rebuild the SkyWalking distribution and OAP Docker image after source changes. Use before running e2e tests so the image reflects your code changes. Avoids the \"image looks updated but runtime has stale jars\" trap.\nargument-hint: \"[oap|all|dist-only]\"\n---\n\n# Package OAP Distribution & Docker Image\n\nRebuilding the Docker image after a source-code change has a **two-step dependency**: rebuild the dist tarball, then rebuild the image. Skipping the first step silently produces an image with stale jars — the Docker build still \"succeeds,\" the image has a fresh timestamp, but the embedded jar is the one from your previous build.\n\n## Why this matters\n\n`make docker.oap` in the root `Makefile` is defined as:\n\n```\ndocker.% push.docker.%: $(CONTEXT)\u002F$(DIST) $(SW_ROOT)\u002Fdocker\u002F%\u002F*\n    $(DOCKER_RULE)\n```\n\nIt depends on `$(CONTEXT)\u002F$(DIST)` (the dist tarball) **as a file prerequisite**. If that tarball already exists, make does not regenerate it — it just copies whatever is on disk into `dist\u002Fdocker_build\u002Foap\u002F` and runs `docker buildx build`. There is **no** dependency that rebuilds the tarball from source.\n\nOnly `make docker` triggers the full chain (`init → build.all → docker.all`). So:\n\n| Command | Rebuilds source? | Rebuilds tarball? | Rebuilds image? |\n|---------|:--:|:--:|:--:|\n| `.\u002Fmvnw -pl \u003Cmodule> package` | only that module | no | no |\n| `.\u002Fmvnw -pl apm-dist -am package -Pbackend,dist` | all backend deps + dist | yes | no |\n| `make docker.oap` | **no** | **no** (uses whatever's on disk) | yes |\n| `make docker` | yes (`build.all`) | yes | yes (`docker.all`) |\n\n## `flatten:flatten` — always run it before `package`\u002F`install`\n\nSkyWalking's poms use `${revision}` as a placeholder version (e.g., `10.5.0-SNAPSHOT`). The `flatten-maven-plugin` resolves `${revision}` into concrete versions and writes a `.flattened-pom.xml`. Without it:\n\n- Installed artifacts carry the literal string `${revision}` in their coordinates and cannot be resolved as dependencies.\n- Downstream modules (including `apm-dist`) see an inconsistent dependency graph.\n- Symptoms are subtle: `-pl \u003Cmodule> -am` may succeed in isolation but fail or pull in stale transitive artifacts when the same module is consumed by another build invocation in the same session.\n\n**Always run `flatten:flatten` in the same goal chain as `package` or `install`.** The CI `dist-tar` job and the `compile` skill both do this. Example:\n\n```bash\n.\u002Fmvnw clean flatten:flatten package -Pbackend,dist -DskipTests\n```\n\nNot optional — treat it as part of `package`.\n\n## Pick the right command\n\n### Changed OAP source → want a new image\n\n```bash\n# Recommended: full chain\nmake docker\n```\n\nor, faster and equivalent for backend-only changes (skips UI):\n\n```bash\n.\u002Fmvnw -pl apm-dist -am -o clean flatten:flatten package -Pbackend,dist -DskipTests -Dcheckstyle.skip=true -Dmaven.javadoc.skip=true\nmake docker.oap\n```\n\n**Do not** just run `make docker.oap` after a code edit — the image will look rebuilt but your change will not be in the jars.\n**Do not** skip `flatten:flatten` — see the section above.\n\n### Changed only the dist packaging (e.g., `apm-dist\u002F`, log4j2.xml)\n\n```bash\n.\u002Fmvnw -pl apm-dist -am -o clean flatten:flatten package -Pbackend,dist -DskipTests\nmake docker.oap\n```\n\n### Changed only Dockerfile \u002F entrypoint (`docker\u002Foap\u002F*`)\n\nThe tarball is untouched, so `make docker.oap` alone is correct:\n\n```bash\nmake docker.oap\n```\n\n## Verify the fix reached the image\n\nDocker's \"image created\" timestamp updates even when the content is stale (because `--no-cache` is used). **Don't trust the timestamp.** Verify the jar contents directly:\n\n```bash\n# Copy the jar out of the container\ndocker cp \u003Ccontainer-name>:\u002Fskywalking\u002Foap-libs\u002F\u003Cmodule>-\u003Cversion>.jar \u002Ftmp\u002Fverify.jar\n\n# Extract the specific class\ncd \u002Ftmp && jar -xf verify.jar \u003Cpath\u002Fto\u002FYourClass.class>\n\n# Grep for a string your fix introduced (unique literal, method name, etc.)\ngrep -oa \"myFixSignature\" \u003Cpath\u002Fto\u002FYourClass.class>\n```\n\nIf grep finds nothing, the image does not contain your fix — you forgot to rebuild the dist. Re-run with the correct chain.\n\n## Common pitfalls\n\n- **`make docker.oap` after `.\u002Fmvnw package`**: The module jar is fresh in `oap-server\u002F...\u002Ftarget\u002F`, but the dist tarball at `dist\u002Fapache-skywalking-apm-bin.tar.gz` is untouched. Image uses the old jar.\n- **Cancelling a `make docker` mid-flight**: leaves the dist half-rebuilt. Re-run `make docker` or delete `dist\u002F` first.\n- **Stale buildx cache**: not usually the issue (the Makefile passes `--no-cache`), but if you suspect it, run `docker buildx prune`.\n- **Trusting image timestamps**: `docker images` shows when the image was *tagged*, not when its content actually changed. A no-op rebuild still updates the timestamp.\n- **Interactive buildx hangs**: if `docker buildx build` sits silent for minutes with no stdout, kill it and retry. The buildx container driver occasionally stalls; a restart is faster than waiting.\n\n## The golden rule\n\nAfter any Java source edit that affects code shipped in `oap-libs\u002F`, run one of:\n\n1. `make docker` (full, safest)\n2. `.\u002Fmvnw -pl apm-dist -am -o package -Pbackend,dist -DskipTests -Dcheckstyle.skip=true && make docker.oap` (fast)\n\nThen **verify the fix is in the image's jar** before running e2e. Don't assume.\n","# Package OAP Distribution & Docker Image\n\nRebuilding the Docker image after a source-code change has a **two-step dependency**: rebuild the dist tarball, then rebuild the image. Skipping the first step silently produces an image with stale jars — the Docker build still \"succeeds,\" the image has a fresh timestamp, but the embedded jar is the one from your previous build.\n\n## Why this matters\n\n`make docker.oap` in the root `Makefile` is defined as:\n\n```\ndocker.% push.docker.%: $(CONTEXT)\u002F$(DIST) $(SW_ROOT)\u002Fdocker\u002F%\u002F*\n    $(DOCKER_RULE)\n```\n\nIt depends on `$(CONTEXT)\u002F$(DIST)` (the dist tarball) **as a file prerequisite**. If that tarball already exists, make does not regenerate it — it just copies whatever is on disk into `dist\u002Fdocker_build\u002Foap\u002F` and runs `docker buildx build`. There is **no** dependency that rebuilds the tarball from source.\n\nOnly `make docker` triggers the full chain (`init → build.all → docker.all`). So:\n\n| Command | Rebuilds source? | Rebuilds tarball? | Rebuilds image? |\n|---------|:--:|:--:|:--:|\n| `.\u002Fmvnw -pl \u003Cmodule> package` | only that module | no | no |\n| `.\u002Fmvnw -pl apm-dist -am package -Pbackend,dist` | all backend deps + dist | yes | no |\n| `make docker.oap` | **no** | **no** (uses whatever's on disk) | yes |\n| `make docker` | yes (`build.all`) | yes | yes (`docker.all`) |\n\n## `flatten:flatten` — always run it before `package`\u002F`install`\n\nSkyWalking's poms use `${revision}` as a placeholder version (e.g., `10.5.0-SNAPSHOT`). The `flatten-maven-plugin` resolves `${revision}` into concrete versions and writes a `.flattened-pom.xml`. Without it:\n\n- Installed artifacts carry the literal string `${revision}` in their coordinates and cannot be resolved as dependencies.\n- Downstream modules (including `apm-dist`) see an inconsistent dependency graph.\n- Symptoms are subtle: `-pl \u003Cmodule> -am` may succeed in isolation but fail or pull in stale transitive artifacts when the same module is consumed by another build invocation in the same session.\n\n**Always run `flatten:flatten` in the same goal chain as `package` or `install`.** The CI `dist-tar` job and the `compile` skill both do this. Example:\n\n```bash\n.\u002Fmvnw clean flatten:flatten package -Pbackend,dist -DskipTests\n```\n\nNot optional — treat it as part of `package`.\n\n## Pick the right command\n\n### Changed OAP source → want a new image\n\n```bash\n# Recommended: full chain\nmake docker\n```\n\nor, faster and equivalent for backend-only changes (skips UI):\n\n```bash\n.\u002Fmvnw -pl apm-dist -am -o clean flatten:flatten package -Pbackend,dist -DskipTests -Dcheckstyle.skip=true -Dmaven.javadoc.skip=true\nmake docker.oap\n```\n\n**Do not** just run `make docker.oap` after a code edit — the image will look rebuilt but your change will not be in the jars.\n**Do not** skip `flatten:flatten` — see the section above.\n\n### Changed only the dist packaging (e.g., `apm-dist\u002F`, log4j2.xml)\n\n```bash\n.\u002Fmvnw -pl apm-dist -am -o clean flatten:flatten package -Pbackend,dist -DskipTests\nmake docker.oap\n```\n\n### Changed only Dockerfile \u002F entrypoint (`docker\u002Foap\u002F*`)\n\nThe tarball is untouched, so `make docker.oap` alone is correct:\n\n```bash\nmake docker.oap\n```\n\n## Verify the fix reached the image\n\nDocker's \"image created\" timestamp updates even when the content is stale (because `--no-cache` is used). **Don't trust the timestamp.** Verify the jar contents directly:\n\n```bash\n# Copy the jar out of the container\ndocker cp \u003Ccontainer-name>:\u002Fskywalking\u002Foap-libs\u002F\u003Cmodule>-\u003Cversion>.jar \u002Ftmp\u002Fverify.jar\n\n# Extract the specific class\ncd \u002Ftmp && jar -xf verify.jar \u003Cpath\u002Fto\u002FYourClass.class>\n\n# Grep for a string your fix introduced (unique literal, method name, etc.)\ngrep -oa \"myFixSignature\" \u003Cpath\u002Fto\u002FYourClass.class>\n```\n\nIf grep finds nothing, the image does not contain your fix — you forgot to rebuild the dist. Re-run with the correct chain.\n\n## Common pitfalls\n\n- **`make docker.oap` after `.\u002Fmvnw package`**: The module jar is fresh in `oap-server\u002F...\u002Ftarget\u002F`, but the dist tarball at `dist\u002Fapache-skywalking-apm-bin.tar.gz` is untouched. Image uses the old jar.\n- **Cancelling a `make docker` mid-flight**: leaves the dist half-rebuilt. Re-run `make docker` or delete `dist\u002F` first.\n- **Stale buildx cache**: not usually the issue (the Makefile passes `--no-cache`), but if you suspect it, run `docker buildx prune`.\n- **Trusting image timestamps**: `docker images` shows when the image was *tagged*, not when its content actually changed. A no-op rebuild still updates the timestamp.\n- **Interactive buildx hangs**: if `docker buildx build` sits silent for minutes with no stdout, kill it and retry. The buildx container driver occasionally stalls; a restart is faster than waiting.\n\n## The golden rule\n\nAfter any Java source edit that affects code shipped in `oap-libs\u002F`, run one of:\n\n1. `make docker` (full, safest)\n2. `.\u002Fmvnw -pl apm-dist -am -o package -Pbackend,dist -DskipTests -Dcheckstyle.skip=true && make docker.oap` (fast)\n\nThen **verify the fix is in the image's jar** before running e2e. Don't assume.\n",{"name":5,"description":7,"argument-hint":37},"[oap|all|dist-only]","master","f4d38fdc21e5a929ef89556a1d7c337957523aa9",".claude\u002Fskills\u002Fpackage",6627,"https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking","https:\u002F\u002Fskywalking.apache.org\u002F","https:\u002F\u002Fgithub.com\u002Fapache","https:\u002F\u002Fwww.apache.org\u002F","2026-11-11 08:56:29",{"source":8,"skillName":5,"commands":48,"prompt":58,"zipAvailable":59},[49,52,55],{"tool":50,"command":51},"npx","npx skills add apache\u002Fskywalking --skill package",{"tool":53,"command":54},"bunx","bunx skills add apache\u002Fskywalking --skill package",{"tool":56,"command":57},"pnpm","pnpm dlx skills add apache\u002Fskywalking --skill package","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fpackage\u002FSKILL.md",true,[],[62,77,86,96,103,119],{"skillNo":63,"name":64,"nameZh":6,"description":65,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":66,"categories":67,"keywords":71,"publishedAt":32},"01M6ACBTY89EEM81A0WWN0QQT3","test","Run unit tests, integration tests, or slow integration tests matching CI. Use to validate changes before submitting a PR.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Ftest\u002FSKILL.md",[68],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量",[64,72,73,74,75,76],"run","unit tests","pr","validate","integration tests",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":84,"publishedAt":32},"01M6ACBRBNXZ57EN1G8GREKFY5","run-e2e","Run SkyWalking E2E tests locally","https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Frun-e2e\u002FSKILL.md",[83],{"categoryNo":69,"categoryName":70,"taxonomyType":21,"taxonomyTypeDesc":22},[72,85,29,31,64],"run e2e",{"skillNo":87,"name":88,"nameZh":6,"description":89,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":90,"categories":91,"keywords":92,"publishedAt":32},"01M6ACBJQMZV0S42P4WMCFFPGP","new-monitoring-feature","Add a new monitoring target \u002F layer to SkyWalking OAP. Orients you to the OAL \u002F MAL \u002F LAL \u002F TAL \u002F SpanListener extension points, the UI template + submodule touchpoints, the docs set that must move together, and the cross-cutting traps that don't live in any one skill.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fnew-monitoring-feature\u002FSKILL.md",[],[93,94,95,31],"new monitoring feature","extension points","docs",{"skillNo":97,"name":98,"nameZh":6,"description":99,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":100,"categories":101,"keywords":102,"publishedAt":32},"01M6ACBG5P0NY2A7AEX89BZNFH","license","Check and fix Apache 2.0 license headers and dependency licenses using skywalking-eyes. Use before submitting a PR.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Flicense\u002FSKILL.md",[],[98,74,9,31],{"skillNo":104,"name":105,"nameZh":6,"description":106,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":107,"categories":108,"keywords":112,"publishedAt":32},"01M6ACBDKKTXZ8Y36YHBADT8JA","gh-pull-request","Verify, commit, and push changes on a PR branch. Runs pre-flight checks (compile, checkstyle, license headers) before every push. Also creates the PR if one doesn't exist yet.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fgh-pull-request\u002FSKILL.md",[109],{"categoryNo":110,"categoryName":111,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",[113,114,115,116,117,74,118],"pull request","gh pull request","pull","commit","compile","push",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":32},"01M6ACBB39DNW4G2SR836V0RA8","generate-classes","Generate bytecode classes from DSL scripts (MAL, OAL, LAL, Hierarchy). Runs the compiler and dumps .class files for inspection.","https:\u002F\u002Fgithub.com\u002Fapache\u002Fskywalking\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fgenerate-classes\u002FSKILL.md",[],[126,127],"generate","generate classes"]