Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

emberjs.tgz appears to be stale #61

Open
ohsnapitscolin opened this issue Jul 23, 2020 · 20 comments
Open

emberjs.tgz appears to be stale #61

ohsnapitscolin opened this issue Jul 23, 2020 · 20 comments

Comments

@ohsnapitscolin
Copy link

Hey! We're running into an issue with https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz and Node 12.18.3.

When building, we get the following error:

-----> emberjs app detected
-----> Setting NPM_CONFIG_PRODUCTION to false to install ember-cli toolchain
-----> Fetching buildpack heroku/nodejs-v98
-----> Node.js detected
-----> Creating runtime environment
       
       NPM_CONFIG_LOGLEVEL=error
       NPM_CONFIG_PRODUCTION=false
       NODE_ENV=production
       NODE_MODULES_CACHE=true
       NODE_VERBOSE=false
-----> Installing binaries
       engines.node (package.json):  12
       engines.npm (package.json):   unspecified (use default)
       
       Resolving node version 12 via semver.io...
       Downloading and installing node 12.18.3...
       Unable to download node 12.18.3; does it exist?
-----> Build failed

We raised an issue with heroku-buildpack-nodejs, but through that process found that we appear to be building with an out of date version (v98) of the buildpack.

A change was made to this repo back in 2019 to unpin version 98: 8760c52, but https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz doesn't seem to reflect that change.

Downloading and extracting the bin and vendor directories, it looks like they were last modified in May of 2017. Is there any chance https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz could be made up to date with the most recent changes?

jtgeibel added a commit to jtgeibel/crates.io that referenced this issue Jul 25, 2020
It appears that the buildpack we were grabbing from S3 is very stale.
That version pins `heroku/nodejs-v98` which is also old (the current
version is v174).

This is causing deploys to fail and has already been [reported]
upstream. This commit pins the current `HEAD` commit of the emberjs
buildpack.

[reported]: heroku/heroku-buildpack-emberjs#61
jtgeibel added a commit to jtgeibel/crates.io that referenced this issue Jul 26, 2020
It appears that the buildpack we were grabbing from S3 is very stale.
That version pins `heroku/nodejs-v98` which is also old (the current
version is v174).

This is causing deploys to fail and has already been [reported]
upstream. This commit pins to a custom built version based on
jtgeibel/heroku-buildpack-emberjs@get-things-building.

[reported]: heroku/heroku-buildpack-emberjs#61
bors added a commit to rust-lang/crates.io that referenced this issue Jul 26, 2020
Bump to the latest emberjs buildpack

It appears that the buildpack we were grabbing from S3 is very stale.
That version pins `heroku/nodejs-v98` which is also old (the current
version is v174).

This is causing deploys to fail and has already been [reported]
upstream. This commit pins to a custom built version based on
jtgeibel/heroku-buildpack-emberjs@34f4175.

I'm trying a staging deploy of this now, and will merge once that succeeds.

r? @ghost

[reported]: heroku/heroku-buildpack-emberjs#61
@jtgeibel
Copy link

I was able to get rake compile working in #62. Then I built on Ubuntu 16.04 (to be compatible with the heroku-16 stack) and packaged a custom *.tgz (mirroring the file layout of the upstream release).

emberjs.tar.gz - Note that I've uploaded this as a .tar.gz so that GH would accept it, but to be compatible with heroku-buildpack-multi the extension must be .tgz.

@rajveerappan
Copy link

rajveerappan commented Jul 28, 2020

@jtgeibel I similarly got it building (using docker-compose run compile) and used the updated binary with Heroku but I noticed that it was still Fetching buildpack heroku/nodejs-v98 when running CI tests. I saw that nodejs-v98 is still used in two places:

buildpacks = %w(heroku/nodejs-v98 heroku/ember-cli-deploy)

BuildpackRunner.new(@output_io, @error_io, "heroku/nodejs-v98").test(@build_dir, @env_dir)

and after unpinning in those two locations my custom build started correctly fetching the latest nodejs buildpack.

Wondering if you saw a similar issue using your custom embjers.tar.gz package with Heroku? Basically I'm not sure if it's sufficient to just publish a new version from master to https://codon-buildpacks.s3.amazonaws.com/buildpacks/heroku/emberjs.tgz or whether the two files I mentioned need to be fixed first.

@jtgeibel
Copy link

@rajveerappan I'm sure you're right, it looks like those lines should be updated as well. Since that's in the tests I don't think it should impact the file I built, but I agree the version should be unpinned there too.

@jtgeibel
Copy link

Oh, I have noticed that it appears the ember application is being built twice with the package I built. I'm guessing that the nodejs buildpack now runs npm run build, and then this buildpack runs it again. I haven't looked into this at all.

@ohsnapitscolin
Copy link
Author

@jtgeibel have you been able to successfully build on Heroku with the custom built package linked in #61 (comment)? We've tried downloading, compressing and hosting it but running into an App not compatible with buildpack: error.

@jtgeibel
Copy link

Hey @ohsnapitscolin, yes I've use that custom built package to build an application on Heroku. To clarify, there should be no need to compress the file, just to rename it to emberjs.tgz. Maybe the file you're hosting was compressed a 2nd time. The other thing I would check is if the web server is sending content-encoding: gzip then maybe the client (downloading the buildpack within the build environment) is decompressing when some later part of the script expects compressed input.

@ohsnapitscolin
Copy link
Author

Thanks @jtgeibel! Not sure if I messed something up during the extracting and re-compressing process, but just simply renaming got it working for me! For anyone else with the issue, downloading emberjs.tar.gz, renaming it to emberjs.tgz and hosting the file yourself should resolve the issue.

It's also worth noting the Heroku seems to now support Node 12.18.3, but probably still best to get off heroku/nodejs-v98.

@imanuelgittens
Copy link

@jtgeibel this helped me a lot! I'm still hopeful that the official buildpack will be updated though.

@lancedikson
Copy link

Running into the same issue. Fixing node version to 12.18.2 fixed the problem for us, but it would be nice not to be blocked by that 🙂

@andrewcallahan
Copy link

Can second that setting node to 12.18.2 works for me! Great temporary solution that finally allows new builds!!

edmorley added a commit that referenced this issue Aug 19, 2020
Since buildkits is deprecated, and the current published version is out
of date (see #61). Whilst we can (and will likely) perform a one-off
publish of `master` to buildkits, it's likely the version there will
become out of date again in the future, so it's just easier to use
GitHub URLs instead.

This buildpack also does not exist on buildpack registry.

Refs #61.
edmorley added a commit that referenced this issue Aug 19, 2020
Since buildkits is deprecated, and the current published version is out
of date (see #61). Whilst we can (and will likely) perform a one-off
publish of `master` to buildkits, it's likely the version there will
become out of date again in the future, so it's just easier to use
GitHub URLs instead.

This buildpack also does not exist on buildpack registry.

Refs #61.
edmorley added a commit that referenced this issue Aug 19, 2020
Since buildkits is deprecated, and the current published version is out
of date (see #61). Whilst we can (and will likely) perform a one-off
publish of `master` to buildkits, it's likely the version there will
become out of date again in the future, so it's just easier to use
GitHub URLs instead.

This buildpack also does not exist on buildpack registry.

Refs #61.
@edmorley
Copy link
Member

edmorley commented Aug 19, 2020

@hone I came across this issue recently (see context in W-7981024) and thought I'd try to quickly push out a new release to resolve the issues here.

I tried using rake publish from the root of this repo, however the Docker build of the compiled binary failed with:

...
Cloning into '/home/mruby/code/mruby/build/mrbgems/mruby-yaml'...
remote: Enumerating objects: 8, done.
remote: Counting objects: 100% (8/8), done.
remote: Compressing objects: 100% (6/6), done.
remote: Total 8 (delta 0), reused 6 (delta 0), pack-reused 0
Unpacking objects: 100% (8/8), done.
Checking connectivity... done.
build: [exec] curl http://pyyaml.org/download/libyaml/yaml-0.1.6.tar.gz | tar -xzv
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   162  100   162    0     0   1142      0 --:--:-- --:--:-- --:--:--  1148

gzip: stdin: not in gzip format
tar: Child returned status 1
tar: Error is not recoverable: exiting now
rake aborted!
curl http://pyyaml.org/download/libyaml/yaml-0.1.6.tar.gz | tar -xzv failed
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:19:in `block in run_command'
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:17:in `run_command'
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:28:in `block (2 levels) in <top (required)>'
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:26:in `chdir'
/home/mruby/code/mruby/build/mrbgems/mruby-yaml/mrbgem.rake:26:in `block in <top (required)>'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:80:in `instance_eval'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:80:in `setup'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:327:in `generate_gem_table'
/home/mruby/code/mruby/mrbgems/mruby-test/mrbgem.rake:35:in `block in <top (required)>'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:80:in `instance_eval'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:80:in `setup'
/home/mruby/code/mruby/tasks/ruby_ext.rake:41:in `block in to_proc'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:290:in `each'
/home/mruby/code/mruby/tasks/mrbgem_spec.rake:290:in `each'
/home/mruby/code/mruby/tasks/mrbgems.rake:4:in `block in <top (required)>'
/home/mruby/code/mruby/tasks/mruby_build.rake:13:in `instance_eval'
/home/mruby/code/mruby/tasks/mruby_build.rake:13:in `block in each_target'
/home/mruby/code/mruby/tasks/mruby_build.rake:12:in `each'
/home/mruby/code/mruby/tasks/mruby_build.rake:12:in `each_target'
/home/mruby/code/mruby/tasks/mrbgems.rake:1:in `<top (required)>'
/home/mruby/code/mruby/Rakefile:26:in `load'
/home/mruby/code/mruby/Rakefile:26:in `<top (required)>'
/home/mruby/code/rakefile:22:in `load'
/home/mruby/code/rakefile:22:in `<top (required)>'
(See full trace by running task with --trace)
rake aborted!
Command failed with status (1): [docker-compose run compile...]

The curl/untar of http://pyyaml.org/download/libyaml/yaml-0.1.6.tar.gz is failing since it now returns an HTTP 301 to the HTTPS URL.

It looks like upstream mruby-yaml has fixed this:
hone/mruby-yaml@master...mrbgems:master

@hone would you mind updating https://github.com/hone/mruby-yaml to s/http/https/ for that URL (or else pulling in the changes from upstream)? I realise this buildpack is not actively maintained, but publishing a new release would really help out the users above (see also the support ticket list in W-7981024). Thanks :-)

@camerondubas
Copy link

With the release of Node 12.18.4 which includes two security patches, getting this buildpack updated has become even more important.

Is there any progress being made here? I'm happy to help if I can.

@musaffa
Copy link

musaffa commented Sep 28, 2020

It's a shame that an official buildpack of Heroku has been left unmaintained for such a long time.

@cloke
Copy link

cloke commented Sep 28, 2020

FWIW pinning to node 12.18.2 also worked for me and then today deploys started failing again. Pinning everything to the last known working version fixed it for me:
"engines": { "node": "12.18.2", "npm": "6.14.5", "yarn": "1.22.5" },

@joekarl
Copy link

joekarl commented Feb 12, 2021

I'm following up on this thread as this buildpack really should get updated as it's un-useable with more recent versions of node (in particular 14+).

A workaround (thanks @James1x0) had was to unpin the node buildpack version (this is done in master currently), build the buildpack binary, and then commit said binary back into the repo at vendor/buildpack. you can then use the .git URL of your repo for specifying the buildpack (in either .buildpacks or buildpacks:set).

This would allow #63 (point to the .git URL of this repo) to be functional even as it's binary based instead of repo based.

All that said, probably a better alternative would be to add a release to this repository that contained the built buildpack binary as a tar.gz and then set the instructions to point to the latest release on github.

I hesitate to recommend forking, building the binary in the fork, and pointing your application at that fork, but it is a work around if you really need this to work today.

@musaffa
Copy link

musaffa commented Mar 13, 2021

I'm using a fork of this repository: https://github.com/James1x0/heroku-buildpack-emberjs

$ heroku buildpacks:set https://buildpack-registry.s3.amazonaws.com/buildpacks/aedev/emberjs.tgz

It provides the updated binary. You can use the latest nodes with this buildpack.

Warning: The fork is a third party buildpack. Use it with your own risk.

@James1x0
Copy link

James1x0 commented Mar 13, 2021

I'm using a fork of this repository: https://github.com/James1x0/heroku-buildpack-emberjs

$ heroku buildpacks:set https://github.com/James1x0/heroku-buildpack-emberjs

It provides the updated binary. You can use the latest nodes with this buildpack.

Warning: The fork is a third party buildpack. Use it with your own risk.

Hi there - we use this fork in some prod apps and try and update it when it breaks. Happy to review any PRs if someone wants to help out! It also has a binary on the official buildpack registry, so make sure and use that instead of the GitHub link unless you like living on the edge :)

@cloke
Copy link

cloke commented Apr 19, 2021

I noticed that the "About" now shows "This buildpack is deprecated! Please use the official Node.js buildpack combined with the static buildpack instead." If anyone has an example of this method that would be great as it appears this build pack won't be receiving updates.

@lancedikson
Copy link

lancedikson commented Jun 15, 2021

@cloke, we don't use fastboot, thus it makes the configuration a little bit easier. Here is what works for us, maybe will be applicable for you as well:

  1. Make sure you've added the following buildpacks to the app:
heroku/nodejs
https://github.com/heroku/heroku-buildpack-static.git

Also, pay attention to the order: during building they should appear exactly in the mentioned order.
2. Add a static.json that points out to the dist dir:

{  
  "root": "dist/",
  "routes": {
    "/**": "index.html"
  }
}
  1. Add build command to the scripts section in package.json:
  "scripts": {    
      "build": "ember build --environment=production",
    ....

That's all. Hope this helps! 🙌🏻

@Subtletree
Copy link

@lancedikson Awsome! Working for me too and feels damn good to get rid of heroku-buildpack-emberjs

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests