ERROR: failed to launch: path lookup: exec: "ruby bin/rails server"

[Hemant28codes]

I created an image using pack build from this repo - link. I also created an image without migrating to libcnb changes and tried booting up a container with both the images. With libcnb v2 we see that we are getting this error:

ERROR: failed to launch: path lookup: exec: "ruby bin/rails server": stat ruby bin/rails server: no such file or directory

The application we are trying to built is - link.

"ruby bin/rails server" - This is the entrypoint of this ruby application and we set it here. If there is an entrypoint we try to add this using AddProcess function defined [here] (https://github.com/Hemant28codes/buildpacks/blob/0e5653369e2ed2e56b5af045e9996bbea0dab5ba/pkg/gcpbuildpack/gcpbuildpack.go#L462) which actually adds this entrypoint in the command array of libcnb.Process. And as a part of migrating we changed Process struct's command to an array of string and removed the direct field. Looks like the issue is with this change only. Could you please help with this one?

[dmikusa]

I am not a Ruby/Rails dev, so I don't really know what that command is doing, but there are some changes to be aware of in the way this works.

1. The command changed from a string to an array. This isn't huge or likely to cause issues beyond compile problems.
2. All commands are now direct. This is likely where you'll see issues.

Direct means there is no shell involved, so any command you would add that relies on a shell being available isn't going to work or may fail in weird ways. The quick and dirty workaround is to use bash -c 'your-original-cmd' as your process type command. That will invoke what you were previously doing in a shell, so it's pretty similar to before this change.

I don't know ruby/rails enough to know if this is the issue you're seeing, but it seems like a good place to start.

[Hemant28codes]

Is there anything that we are supposed to change in the arguments provided to libcnb.Process?.

[dmikusa]

I don't think so. The only thing that comes to mind is that a shell might be more permissive. With direct process types, if you set a command of echo and args of ["1", "2", "3"] then it will echo '1' '2' '3'. If you echo with args of ["1 2 3"] then it's like saying echo '1 2 3' (all as one argument).

[Hemant28codes]

Okk, so as per my understanding, with libcnb v1 we were having a command array and what we used to do was to pass cmd[0] in the libcnb.Process.command and cmd[1:] i.e. remaining array into libcnb.Process.arguments, whether its direct or not.

Now with libcnb v2 if we want that direct should be false the we should pass libcnb.Process.Command = ["bash", "-c", strings.Join(myCommandArray, "")] and Args should be empty. And with direct as true we should pass libcnb.Process.Command = [myCommandArray[0]] and Args should be empty myCommandArray[1:] i.e. the remaining array. Am i getting it right?

[dmikusa]

Yes, I can't guarantee that will 100% work in all situations, but often wrapping the command with bash -c will make it run like it was running prior to the removal of non-direct process types, so this is a good place to start when you're migrating.