Should gem projects be supported here? #761
Comments
|
Hey @fgrehm, thanks for the details. To me, this seems like a solid use case to support in the buildpacks, so I'd like to investigate what this would look like. I'd love to see the build logs from the failed build if possible? Also some information on the structure of your project would be helpful |
|
Hey Sophie! Thanks for the reply. I'll look into preparing a minimal reproducible example to share with you folks this week. |
|
Sorry folks, haven't been able to get to this last week but will try this one |
|
No rush, we'll take a look whenever you have time |
|
Hey @fgrehm is this still an issue for you? |
|
Sorry for the delay! Here's how to reproduce: Click to see commandsEnvironment: Create gem: Edit gemspec to remove unecessary attributes and Edit executable to output some text for debugging and confirm it works: Build app: Try to run it: As I mentioned on the issue description, we have a way to work around this, the issue is that git is not present on the runtime image, neither the I'm just wondering if there's anything we could do here besides providing guidance on official documentation on how to fix that error message. I think the answer is no, but maybe you folks have ideas 😄 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What happened?
What were you attempting to do?
Build an image for a project that is also published as a gem for internal use. TLDR it is a gem that is used by client apps for "kafka interactions" which also bundles some reusable tasks that we run across all of our staging clusters through a Docker image built with CNB buildpacks.
Yes we could write a
Dockerfileinstead but it'd be amazing if we could just leverage the same CNB infra we have for other ruby / rails projects we maintain.What did you expect to happen?
Build should succeed, but we hit a few snags. Also, FWIW I have no idea if other builders like heroku's support this use case, so totally fine if you folks feel like this is not something you wanna move forward with
What was the actual behavior? Please provide log output, if possible.
Some of the "snags" mentioned above include:
.gemspec: fixed by settingBP_BUNDLER_VERSIONgitcommand on gemspec*.gemspecgenerated for ruby gems make use ofgit ls-filesto specify the files to be added to the gem when it's released. We worked around this by changing to something like rails' gemspec.gemspecalso had aspec.metadata["revision"] = `git describe`in it and things also failed at runtime because we don't havegitavailable. We solved that by changing it to acat REVISION || git describe(REVISIONis created by our custom builder)Build Configuration
What platform (
pack,kpack,tektonbuildpacks plugin, etc.) are you using? Please include a version.We got our own way of building things, including a base image that builds on top of paketo stacks (only using the
fullone for real ATM). It relies on the execution of individual steps withlifecycleCLI as we kinda reimplement thelifecycle creatorwith some additional logic that makes sense to us (ex: a custom cache fallback mechanism we use).The builder is being created by
packv0.24.0, so it uses whateverlifecyclerelease it injects under the hood.What buildpacks are you using? Please include versions.
Click to see
Can you provide a sample app or relevant configuration (
buildpack.yml,nginx.conf, etc.)?Sure, please see note below, happy to provide more info if you really want to pursue this
Checklist
Note yet, see note below
NOTE: Guidance needed
I'm happy to provide additional information like logs and test cases for you folks to see what we're experiencing but at this stage I'm mostly interested in knowing whether providing better support for apps that have
.gemspecs is something you are interested in pursuing or not 😄I'd also wonder in which repo I should open the issue, like here, or one of the ruby's "sub-buildpacks"
The text was updated successfully, but these errors were encountered: