-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bundler-cache feature breaks ruby-lsp and other default gem behavior #55
Comments
Yes I've also experienced this... I think My feeling was that it was some kind of timing issue with ruby-lsp being run before cache was built at devcontainer build I played around with creating this cache using the devcontainer lifecycle hooks with... not 100% results... sometimes would work sometimes wouldn't :) |
Hi, sorry you are experiencing this issue. I am going to be away for a couple weeks starting tonight and I don't think I will have time to fix this today. @patriciomacadden maybe you can take a look? Probably we do need to do something with the bin path after all. |
Hey everyone, thanks for the feedback! I haven't experienced this unfortunately. I just created a new rails app by running
However, I did experience this right after adding it to an existing image, meaning that I had to run @JeremiahChurch have you run btw, as @andrewn617 and I discussed in #48 , Can you share your |
The best application I can demo this on is a bullettrain copy app using effectively the dockerfile, compose.yaml & devcontainer.json from this PR https://github.com/bullet-train-co/bullet_train/pull/1620/files the devcontainer postCreateCommand runs some scripts that run bundle install along with some other 'prep' actions. while testing when the app is booting and running through installing the bundled gems without the bundle-cache feature enabled ruby-lsp starts and indexes before bundle install even completes. uncommenting the bundle-cache feature and hitting rebuild on the devcontainer - the app boots without doing a bundle install as it's already cached but immediately pops the "Ruby LSP client: couldn't create connection to server" popup in the IDE. opening a terminal, running my complete devcontainer.json devcontainer.json
// For format details, see https://aka.ms/devcontainer.json. For config options, see the
// README at: https://github.com/devcontainers/templates/tree/main/src/ruby
{
"name": "demo",
"dockerComposeFile": "compose.yaml",
"service": "rails-app",
"workspaceFolder": "/workspaces/${localWorkspaceFolderBasename}",
// Features to add to the dev container. More info: https://containers.dev/features.
"features": {
"ghcr.io/devcontainers/features/github-cli:1": {},
"ghcr.io/devcontainers/features/node:1": {},
"ghcr.io/rails/devcontainer/features/activestorage": {},
"ghcr.io/rails/devcontainer/features/postgres-client": {},
"ghcr.io/rails/devcontainer/features/bundler-cache:1": {}
},
"containerEnv": {
"REDIS_URL": "redis://redis:6379/1",
"PGHOST": "postgres",
"PGUSER": "postgres",
"PGPASSWORD": "postgres",
"CAPYBARA_SERVER_PORT": "45678",
"SELENIUM_HOST": "selenium"
// "MEMCACHE_SERVERS": "memcached:11211"
},
// Use 'forwardPorts' to make a list of ports inside the container available locally.
"forwardPorts": [3000, 5432, 6379],
// Configure tool-specific properties.
// "customizations": {},
// Uncomment to connect as root instead. More info: https://aka.ms/dev-containers-non-root.
// "remoteUser": "root",
// Use 'postCreateCommand' to run commands after the container is created.
"postCreateCommand": "corepack enable && yarn set version 4.2.2 && bin/setup-devcontainer",
"customizations": {
"vscode": {
"extensions": [
"GitHub.copilot",
"GitHub.copilot-chat",
"marcoroth.stimulus-lsp",
"bradlc.vscode-tailwindcss",
"Shopify.ruby-lsp",
"eamodio.gitlens",
"karunamurti.haml"
// "manuelpuyol.erb-linter",
// "setobiralo.erb-commenter",
// "streetsidesoftware.code-spell-checker",
// "donjayamanne.githistory",
// "esbenp.prettier-vscode",
// "jemmyw.rails-fast-nav",
// "tmikoss.rails-latest-migration"
]
}
}
} Dockerfile
compose.yaml name: "demo"
services:
rails-app:
build:
context: ..
dockerfile: .devcontainer/Dockerfile
volumes:
- ../..:/workspaces:cached
# Overrides default command so things don't shut down after the process ends.
command: sleep infinity
# Uncomment the next line to use a non-root user for all processes.
# user: vscode
# Use "forwardPorts" in **devcontainer.json** to forward an app port locally.
# (Adding the "ports" property to this file will not forward from a Codespace.)
depends_on:
- redis
- postgres
- selenium
# Use "forwardPorts" in **devcontainer.json** to forward an app port locally.
# (Adding the "ports" property to this file will not forward from a Codespace.)
ports:
- 45678:45678
environment:
COREPACK_ENABLE_DOWNLOAD_PROMPT: 0 # prevent yarn install y/n prompt
selenium:
image: seleniarm/standalone-chromium
restart: unless-stopped
redis:
image: redis:7.2
restart: unless-stopped
volumes:
- redis-data:/data
postgres:
image: postgres:17rc1
restart: unless-stopped
networks:
- default
volumes:
- postgres-data:/var/lib/postgresql/data
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
# memcached:
# image: memcached:latest
# restart: unless-stopped
# command: ["-m", "1024"]
volumes:
redis-data:
postgres-data: Please let me know if I can provide anything else! |
Hmm, interesting. So, I've tried a couple of things:
I also removed the volumes a bunch of times. can you try that as well? It's working in all scenarios for me, so makes me wonder if I'm reproducing the issue the way you're doing it 🤔 . Please let me know if I misinterpreted anything.
this is because @JeremiahChurch can you share the output of RubyLSP? (cmd-j -> output tab -> select ruby lsp in the right hand side). Hopefully we can see what's going on in there. Also, can you see what's in |
I'm on a different machine but it has a very similar dev environment - experiencing the same issue. as requested here's a copy of ruby lsp output and PATH for without feature (working) and with feature (not working) I'll attempt adding/removing volumes to see if the behavior is any different. The common pattern for me certainly has been existing app and beginning to use devcontainer - not starting fresh. Please let me know if anything looks interesting or if you need anything else, really appreciate the help! path shows the same for both situations
WITHOUT FEATURE
WITH FEATURE
|
I didn't think this had anything to do with it because I have couple of projects running with devcontainer (added with I can now reproduce the error. Unfortunately, it seems to be something to do with ruby-lsp. See Shopify/ruby-lsp#2607. Apparently setting So, removed the volume and tried again, and this is what I found: ruby-lsp's initialization creates a On a newly created container, the $ which ruby-lsp
/home/vscode/.rbenv/shims/ruby-lsp but then when you run it, it fails: $ ruby-lsp
Ruby LSP> Skipping custom bundle setup since /workspaces/timetracker/.ruby-lsp/Gemfile.lock already exists and is up to date
Ruby LSP> Running bundle install for the custom bundle. This may take a while...
Ruby LSP> Command: (bundle check || bundle install) 1>&2
The Gemfile's dependencies are satisfied
bundler: failed to load command: ruby-lsp (/bundle/vendor/ruby/3.3.0/bin/ruby-lsp)
/bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/rubygems_integration.rb:265:in `block in replace_bin_path': can't find executable ruby-lsp for gem ruby-lsp. ruby-lsp is not currently included in the bundle, perhaps you meant to add it to your Gemfile? (Gem::Exception)
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/rubygems_integration.rb:293:in `block in replace_bin_path'
from /bundle/vendor/ruby/3.3.0/bin/ruby-lsp:25:in `<top (required)>'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/cli/exec.rb:58:in `load'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/cli/exec.rb:58:in `kernel_load'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/cli/exec.rb:23:in `run'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/cli.rb:451:in `exec'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/vendor/thor/lib/thor/command.rb:28:in `run'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/vendor/thor/lib/thor.rb:527:in `dispatch'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/cli.rb:34:in `dispatch'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/vendor/thor/lib/thor/base.rb:584:in `start'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/cli.rb:28:in `start'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/exe/bundle:28:in `block in <top (required)>'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/lib/bundler/friendly_errors.rb:117:in `with_friendly_errors'
from /bundle/vendor/ruby/3.3.0/gems/bundler-2.5.6/exe/bundle:20:in `<top (required)>'
from /home/vscode/.rbenv/versions/3.3.4/bin/bundle:25:in `load'
from /home/vscode/.rbenv/versions/3.3.4/bin/bundle:25:in `<main>' if you try to run the exe directly, you'll notice that If you run $ ruby-lsp
Ruby LSP> Skipping custom bundle setup since LSP dependencies are already in /workspaces/timetracker/.ruby-lsp/Gemfile
Ruby LSP> Running bundle install for the custom bundle. This may take a while...
Ruby LSP> Command: (bundle check || bundle install) 1>&2
The Gemfile's dependencies are satisfied if you run outside (in your project's root folder), it doesn't work (same output as the error above). If you run using the absolute path to the bin directory ( If you run using the absolute path to the gem directory ( Prepending I now don't understand what's the difference between a newly created project vs an existing one - at some point, both scenarios build the image/container from scratch. |
I'm still trying to understand what's the difference between a newly created rails project vs an existing one with new devcontainer config. Both have pretty much the same setup: same With the existing project with new devcontainer config, however, it seems to break when the rubygems bin (
Question for @andrewn617. Off-topic and out of curiosity, why are we using rbenv in the devcontainer? If we stick to just one ruby version (for example using ruby's official docker images as our base image), it would be easier to just set up |
@patriciomacadden a hacky fix for this is to add another This restores This feels more right because it restores the functionality to 'base' before installing the feature while still having the persisted gem storage for faster boots. I'm not sure of the downfalls of this. I'm sure it could also be handled as a script to better match multiple ruby versions. Since that ruby version folder is a moving target. Something like Pulling the script back to an install.sh with some in-line comments would probably be the clearest way to communicate intent of all the implementation details. If you think that all sounds workable let me know and I'll pull together a PR |
hey @JeremiahChurch , that indeed solves it. But I feel like it's a bit hacky to export the env var in the I'm still trying to figure out why this feature works for newly created projects but not for an existing one - I think that is key. |
running into the same issue. following up 🙏 |
Hey all, could you please check, if my change in rails/rails#53161 would solve your issues? Thanks a lot. |
Love the boot time saves provided by bundler-cache but it breaks most default external gem behavior.
rails
and other gems are not available on the command line after enabling bundler-cache as a featurethis prevents ruby-lsp and other common IDE add-ons from running correctly.
without bundler-cache feature:
with bundler-cache feature:
I'm not enough of a smarty to know the right fix for this. I'm assuming a modification of the gem paths needs to be done but I'm unsure of the best way to implement that change within this feature bundle.
Would love if anyone has and ideas or pointers on the right direction of a fix. Thank you all <3
environment: unchanged Dockerfile for ruby 3.3.5, activestorage, postgres-client, github-cli & node devcontainer features
The text was updated successfully, but these errors were encountered: