Awesome - I mentioned this 400+ days ago when the platform API was announced! Cool to see it getting rolled out, looking forward to playing around with this.
Heroku should consider using SVG for the badge, just like shields.io and services like Travis CI do. The current button is blurry on a retina screen, and basic SVG is really well supported.
That may be the case, but there's many contexts where you'd use this button where you can't alter the page's CSS. Perhaps the prime example being GitHub READMEs.
I'm not on a retina display but that doesn't look as nice. The letters are so thin they start to disappear even before using the light-purple-on-dark-purple font.
Judging by my windows machine and using just my eyes, yes, it's a little thinner, and no, there's no problem reading it. The faded-grey-ness of the words "to Heroku" is a much bigger legibility problem than the minor change in font weight.
Obviously I never really promoted it and I'm glad to see that Heroku built something official. But maybe someone far in the future will see this comment and remember :)
I think they're still working out the kinks [1], but nevertheless, great when it works. No more 'behind' hosted demos for open-source apps, just let them instantly deploy it and play with it on their own.
Does this support normal Git links? If so, you could simply link to a Gumroad or similar site and have that send a Heroku Button link with a customized git repo where they can deploy from.
I imagine you need to set up your app to use Heroku. It's not very hard but beware that you can't write to the filesystem with Heroku so that would need to be factored in to the functionality of quite a few apps.
You can write to the file system, it's just not persistent across dyno restarts or shared across running dynos. Writing out for in-request work is fine.
Right now buttons only work with source code hosted on GitHub (although the button can be added anywhere). We want to extend that to other source code hosting services, though.
The button only works with GitHub repos at this time, but if you can place the button on other sites by using the ?template= parameter to point back to the GitHub repo. If you would like to have an app.json in a non-GitHub repo (or any source in a tarball for that matter), you can use the app-setup API (https://devcenter.heroku.com/articles/platform-api-reference...) to do the deployment.
Right now buttons only work with source code hosted on GitHub (although the button can be added anywhere). We want to extend that to other source code hosting services, though.
The challenge is that we have to resolve the [app.json][1] file to generate the deploy UI.
> Note that the snippet is repo-agnostic: It can be copy-pasted without modification and will work correctly if forked to a different repo. Heroku resolves the repo originating a button click by inspecting the referer header.
Is the referer reliable enough on modern browsers to assume this? Perhaps coming from an analytics perspective, we see all types of query-string hacks so that you can attribute the sources of links everywhere... so it's surprising to see a company depend on this functionality in a product. I suppose almost all developers would be using a browser that correctly sends referer headers... is this the case?
They do mention an alternative where you can set stuff in the query string. I'd probably rather do that instead. Especially since you could easily end up putting that button out of the context of your repo at some point and have it end up completely broken.
But if I fork a repo with a button (or even navigate to different branch/commit in same repo), a manually set query string would still point to the same code.
Whereas the referer headear can identify exactly the right version briliantly.
This is amazing, it's a simple app but https://github.com/aaronbassett/Bad-Tools only needed 1 single line change to work. Really impressed although I do need to read up more on the app.json schema.
> This is extremely clever. One of the reasons WordPress took off was the easy, non-technical install process.
Ironically Wordpress is a pain in the ass to deploy on "non persistent/deploy with git" PAAS.And uploading plugins directly through the admin is a no go in these cases.
Worpdress wouldnt deploy directly with that one click install,given the fact the configuration is hardwritten on the disk.It would need some refactoring.
You'd need at least to enter some env variables to make things work,and the app would need to detect the db state and run migrations,if not properly initalized,when using a RDBMS(since again,sqlite is out of question on Heroku).
All the same that Wordpress could easily adopt using environmental variables for configuration values to achieve this and simply use a heroku-ified version of config.php. I've used this approach for scaling wordpress sites and its never failed me.
Anyone else having a lot of problems getting it to work. I keep getting a "Something went wrong" message with no additional information. Even if I create a minimum viable app.json, nothing seems to work.
Kudos, now that's good business: it benefits both the company (because once you're there and it works, you're less likely to switch to another host) and the users who want to quickstart something.
https://news.ycombinator.com/item?id=5793441
EDIT: Setup was pretty smooth - one click deploy for my RSS reader now: https://github.com/swanson/stringer