You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@answer.apache.org by "bendemeyer (via GitHub)" <gi...@apache.org> on 2025/01/23 16:32:19 UTC

[I] Building plugins with docker results in a successful build with no plugins installed [answer]

bendemeyer opened a new issue, #1235:
URL: https://github.com/apache/answer/issues/1235

   I'm not sure if this issue is more appropriate here or in `answer-plugins`, since it relates to plugins but seems like it might be an issue with `answer build` generally. Anyway, I'm putting it in both and I can delete one if its in the wrong place.
   
   I'm trying to get answer running with some plugins, using the docker build process described here: https://answer.apache.org/docs/plugins/#docker-build
   
   When I do this the `answer build` step completes successfully, but when I run `answer plugin` with the new binary I get an empty output. If I run the server and access the admin area, it shows no plugins are installed.
   
   To troubleshoot, I set up a builder image with this basic Dockerfile:
   ```
   FROM apache/answer AS answer-source
   
   FROM golang:1.22-alpine AS golang-builder
   
   COPY --from=answer-source /usr/bin/answer /usr/bin/answer
   
   RUN apk --no-cache add build-base git bash nodejs npm go
   RUN npm install -g pnpm@8.9.2
   ```
   
   And within that I run
   ```
   answer build --with github.com/apache/answer-plugins/render-markdown-codehighlight --output /usr/bin/answer_new
   ```
   
   That process runs, compiles, and appears to complete successfully. However, the plugins aren't actually installed in the output binary.
   ```
   /go # answer_new plugin
   /go # 
   ```
   
   I can also see that the newly built binary is a little smaller than the original:
   ```
   /usr/bin # ls -lah | grep answer
   -rwxr-xr-x    1 root     root       74.3M Nov 22 06:56 answer
   -rwxr-xr-x    1 root     root       68.5M Jan 23 15:05 answer_new
   ```
   
   I'm running this on an M1 mac, and I've replicated this result in both arm & amd64 container architectures. I've also tried upgrading the build container to the latest version of `pnpm` to see if that made a difference, and it did not.
   
   This is the (mostly) complete console output I get when I run `answer build`, with some of the big-long-lists-of-things truncated for the sake of making it more readable:
   ```
   /go # answer build --with github.com/apache/answer-plugins/render-markdown-codehighlight --output /usr/bin/answer_new
   try to build a new answer with plugins:
   github.com/apache/answer-plugins/render-markdown-codehighlight
   [build] build dir: /go/answer_build4202246818
   [go mod tidy]
   go: finding module for package github.com/apache/incubator-answer/cmd
   go: finding module for package github.com/apache/answer-plugins/render-markdown-codehighlight
   go: downloading github.com/apache/answer-plugins v1.2.1
   go: downloading github.com/apache/answer-plugins/render-markdown-codehighlight v1.0.0
   go: downloading github.com/apache/incubator-answer v1.4.1
   go: found github.com/apache/answer-plugins/render-markdown-codehighlight in github.com/apache/answer-plugins/render-markdown-codehighlight v1.0.0
   go: found github.com/apache/incubator-answer/cmd in github.com/apache/incubator-answer v1.4.1
   go: downloading github.com/apache/answer-plugins/util v1.0.3-0.20250107030257-cf94ebc70954
   go: downloading github.com/apache/answer v1.4.2-RC1.0.20250107023923-061894735091
   go: downloading github.com/gin-gonic/gin v1.10.0
   <TRUNCATED: "go: downloading {something}">
   [go mod vendor]
   [go list -mod=mod -m -f {{.Dir}} github.com/apache/incubator-answer]
   try to copy dir from /go/answer_build4202246818/vendor/github.com/apache/incubator-answer-plugins to /go/answer_build4202246818/vendor/github.com/apache/incubator-answer/ui/src/plugins
   [pnpm pre-install]
   
   > answer-static@0.1.0 pre-install /go/answer_build4202246818/vendor/github.com/apache/incubator-answer/ui
   > node ./scripts/importPlugins.js && pnpm install && node ./scripts/preinstall.js 
   
   Lockfile is up to date, resolution step is skipped
   Packages: +1591
   +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
   
      ╭──────────────────────────────────────────────────────────────────╮
      │                                                                  │
      │                Update available! 8.9.2 → 9.15.4.                 │
      │   Changelog: https://github.com/pnpm/pnpm/releases/tag/v9.15.4   │
      │                Run "pnpm add -g pnpm" to update.                 │
      │                                                                  │
      │      Follow @pnpmjs for updates: https://twitter.com/pnpmjs      │
      │                                                                  │
      ╰──────────────────────────────────────────────────────────────────╯
   
   Downloading registry.npmjs.org/typescript/4.9.5: 11.62 MB/11.62 MB, done
   Progress: resolved 1591, reused 0, downloaded 1589, added 1591, done
   node_modules/.pnpm/core-js-pure@3.25.2/node_modules/core-js-pure: Running postinstall script, done in 34ms
   node_modules/.pnpm/core-js@3.25.2/node_modules/core-js: Running postinstall script, done in 32ms
   
   dependencies:
   + @codemirror/lang-markdown 6.2.5
   + @codemirror/language-data 6.5.1
   + @codemirror/state 6.4.1
   + @codemirror/view 6.26.3
   + axios 1.7.7
   + bootstrap 5.3.2
   <TRUNCATED: "+ {dependency}">
   
   devDependencies:
   + @commitlint/cli 17.1.2
   + @commitlint/config-conventional 17.2.0
   + @fullhuman/postcss-purgecss 4.1.3
   + @testing-library/dom 8.18.1
   + @testing-library/jest-dom 4.2.4
   <TRUNCATED: "+ {dependency}">
   
   . prepare$ pnpm build:packages
   │ > answer-static@0.1.0 build:packages /go/answer_build4202246818/vendor/github.com/apache/incubator-answer/ui
   │ > pnpm -r --filter=./src/plugins/* run build
   │ No projects matched the filters in "/go/answer_build4202246818/vendor/github.com/apache/incubator-answer/ui"
   └─ Done in 555ms
   Done in 9.9s
   [pnpm build]
   
   > answer-static@0.1.0 build /go/answer_build4202246818/vendor/github.com/apache/incubator-answer/ui
   > node ./scripts/env.js && react-app-rewired build
   
   Creating an optimized production build...
   Browserslist: caniuse-lite is outdated. Please run:
     npx update-browserslist-db@latest
     Why you should do it regularly: https://github.com/browserslist/update-db#readme
   Browserslist: caniuse-lite is outdated. Please run:
     npx update-browserslist-db@latest
     Why you should do it regularly: https://github.com/browserslist/update-db#readme
   Compiled with warnings.
   
   Module not found: Error: Can't resolve 'buffer' in '/go/answer_build4202246818/vendor/github.com/apache/incubator-answer/ui/node_modules/.pnpm/js-yaml@3.14.1/node_modules/js-yaml/lib/js-yaml/type'
   BREAKING CHANGE: webpack < 5 used to include polyfills for node.js core modules by default.
   This is no longer the case. Verify if you need this module and configure a polyfill for it.
   
   If you want to include a polyfill, you need to:
   	- add a fallback 'resolve.fallback: { "buffer": require.resolve("buffer/") }'
   	- install 'buffer'
   If you don't want to include a polyfill, you can use an empty module like this:
   	resolve.fallback: { "buffer": false }
   
   Search for the keywords to learn more about each warning.
   To ignore, add // eslint-disable-next-line to the line before.
   
   File sizes after gzip:
   
     102.29 kB  build/static/js/codemirror.8ce63365.js
     70.83 kB   build/static/js/lezer.5966669a.js
     65.01 kB   build/static/js/chunk-nodesInitial.2237608c.chunk.js
     49.13 kB   build/static/js/main.dadb9922.js
     48.88 kB   build/static/js/chunk-mix2.e38b5d14.chunk.js
     <TRUNCATED: "{size} {filename}">
   
   The project was built assuming it is hosted at /.
   You can control this with the homepage field in your package.json.
   
   The build folder is ready to be deployed.
   You may serve it with a static server:
   
     npm install -g serve
     serve -s build
   
   Find out more about deployment here:
   
     https://cra.link/deployment
   
   try to merge i18n files
   i18n dir:  /go/answer_build4202246818/vendor/github.com/apache/answer-plugins/render-markdown-codehighlight/i18n
   [go build -ldflags -X github.com/apache/incubator-answer/cmd.Version=1.4.1 -X github.com/apache/incubator-answer/cmd.Revision=c2ad8c6 -X github.com/apache/incubator-answer/cmd.Time=1732256436 -o /usr/bin/answer_new .]
   build new answer successfully /usr/bin/answer_new
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@answer.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Building plugins with docker results in a successful build with no plugins installed [answer]

Posted by "bendemeyer (via GitHub)" <gi...@apache.org>.
bendemeyer commented on issue #1235:
URL: https://github.com/apache/answer/issues/1235#issuecomment-2616145429

   > Maybe in the plugin, we can set a minimum version of Answer to be supported.
   
   Something like this seems like a great idea to me! If the plugin "releases" can hold metadata about which versions of core `answer` they support, then the `answer build` process could potentially account for that, and install the latest version of each requested plugin that's compatible with whichever version of `answer` that's being built.
   
   Another possible change that occurred to be is about the default version of `answer` that gets built if `ANSWER_MODULE` isn't defined. Would it make more sense to have it default to the same version as the current binary, as opposed to the latest release? The advantage to that change would be simplifying the docker build process, as whichever container you start with is the one you'll build. The biggest disadvantage I see is that it would make upgrading an existing installation in-place a little more complicated.
   
   After poking around in the build code, I think I have a pretty good idea of how that second change might be implemented. If it would be desirable, I can test it out and open a PR.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@answer.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Building plugins with docker results in a successful build with no plugins installed [answer]

Posted by "bendemeyer (via GitHub)" <gi...@apache.org>.
bendemeyer commented on issue #1235:
URL: https://github.com/apache/answer/issues/1235#issuecomment-2613209491

   @LinkinStars One follow-up note on this as well, the second approach you outlined (using the older plugin versions with answer@v1.4.1) worked exactly as described, but the first (using answer@v1.4.2-RC2 with the newest plugins) needed some tweaking.
   
   In a golang-builder container based on the `apache/answer:1.4.2-RC2` image, when I tried to run this build command:
   ```
   answer build --with github.com/apache/answer-plugins/render-markdown-codehighlight --output /usr/bin/answer_new
   ```
   
   It errored with the following result:
   ```
   try to build a new answer with plugins:
   github.com/apache/answer-plugins/render-markdown-codehighlight
   [build] build dir: /go/answer_build4074786202
   [go mod tidy]
   go: finding module for package github.com/apache/answer/cmd
   go: finding module for package github.com/apache/answer-plugins/render-markdown-codehighlight
   go: found github.com/apache/answer-plugins/render-markdown-codehighlight in github.com/apache/answer-plugins/render-markdown-codehighlight v1.0.0
   go: found github.com/apache/answer/cmd in github.com/apache/answer v1.4.1
   go: answer imports
           github.com/apache/answer/cmd: github.com/apache/answer@v1.4.1: parsing go.mod:
           module declares its path as: github.com/apache/incubator-answer
                   but was required as: github.com/apache/answer
   ```
   
   I noticed it was still trying to pull `answer@v1.4.1` as its starting point and figured that was the cause of the problem. I found this comment in the build script which suggests this is probably expected behavior since 1.4.2 hasn't actually been released yet:
   > // If user specify a module replacement, use it. Otherwise, use the latest version.
   
   I was then able to specify a module replacement using the `ANSWER_MODULE` environment variable, and that ultimately did the trick. I updated my Dockerfile like so and it works now:
   ```
   FROM apache/answer:1.4.2-RC2 AS answer-source
   
   FROM golang:1.22-alpine AS golang-builder
   
   ENV ANSWER_MODULE="github.com/apache/answer@v1.4.2-RC2"
   
   ......
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@answer.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Building plugins with docker results in a successful build with no plugins installed [answer]

Posted by "LinkinStars (via GitHub)" <gi...@apache.org>.
LinkinStars commented on issue #1235:
URL: https://github.com/apache/answer/issues/1235#issuecomment-2611407820

   @bendemeyer Due to recent adjustments to the repo name during the graduation process, this issue has arisen. There are two possible solutions: if version 1.4.1 is being used, then lower-version plugins must be specified. If the latest version 1.4.2 is being used, the latest version plugins can be utilized.
   
   Use the latest version to build. For docker
   
   ```dockerfile
   FROM apache/answer:1.4.2-RC2 as answer-source
   ```


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@answer.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Building plugins with docker results in a successful build with no plugins installed [answer]

Posted by "bendemeyer (via GitHub)" <gi...@apache.org>.
bendemeyer commented on issue #1235:
URL: https://github.com/apache/answer/issues/1235#issuecomment-2612946032

   @LinkinStars Thanks for the explanation!
   
   One of the goals I'm aiming for in the way I set up my instance is to minimize long-term maintenance overhead, including things like explicit version management. Ideally I'd like to be able to update to the latest release just by re-running the build with my existing Dockerfile.
   
   Do you think it would be possible to establish a versioning/tagging pattern between the `apache/answer` and `apache/answer-plugin` projects that would guarantee (or at least as close to that as is possible in software) compatibility between dynamically referenced objects? Maybe something like `@stable` and `@latest` tags?
   
   I don't know much about these projects yet, so I'm not sure how much overhead would go into implementing & maintaining something like that. If it's doable, I'd be happy to contribute if I can get some pointers on where to start.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@answer.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Building plugins with docker results in a successful build with no plugins installed [answer]

Posted by "LinkinStars (via GitHub)" <gi...@apache.org>.
LinkinStars commented on issue #1235:
URL: https://github.com/apache/answer/issues/1235#issuecomment-2613751954

   @bendemeyer Great!
   
   The issue is due to a recent repository name change. The name was `incubator-answer` modified to `answer` since the project had not graduated. Thank you for your efforts and we apologize for the unnecessary trouble this issue has caused you. After the name is confirmed, this problem will not occur again.
   
   > Do you think it would be possible to establish a versioning/tagging pattern between the `apache/answer` and `apache/answer-plugin` projects that would guarantee (or at least as close to that as is possible in software) compatibility between dynamically referenced objects? Maybe something like `@stable` and `@latest` tags?
   
   For plugins, we support specifying the latest version of the plugin. For example:
   `github.com/apache/answer-plugins/render-markdown-codehighlight@latest`
   
   Then for you to mention establishing a correlation about the version between the two is a good idea. Maybe in the plugin, we can set a minimum version of `Answer` to be supported. Because usually, higher versions are compatible with lower versions. This part needs to be considered more. 🤔
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@answer.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Re: [I] Building plugins with docker results in a successful build with no plugins installed [answer]

Posted by "bendemeyer (via GitHub)" <gi...@apache.org>.
bendemeyer closed issue #1235: Building plugins with docker results in a successful build with no plugins installed
URL: https://github.com/apache/answer/issues/1235


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@answer.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org