Skip to content

Conversation

@krisalyssa
Copy link

The only file changed is scrolls/heroku.rb. Not sure why the other commits got wrapped up in this pull request; I thought I rebased.

@drnic
Copy link
Owner

drnic commented Apr 12, 2012

To bring in a new target deployment host (Heroku, CF, etc), we need to ensure that appscrolls works as expected - prevent scrolls that aren't applicable (mysql on heroku?), and modify others to work (create Procfiles as necessary).

@krisalyssa
Copy link
Author

I’ll start digging through the current scrolls looking for what look to be sensible changes.

Craig S. Cottingham added 2 commits April 12, 2012 18:25
Signed-off-by: Craig S. Cottingham <craig.cottingham@hrworx.com>
@krisalyssa
Copy link
Author

Any idea how one scroll can prevent another one? I see the “exclusive” config key, but that doesn’t feel like the right solution.

@drnic
Copy link
Owner

drnic commented Apr 12, 2012

Hmm, good question.

Something related is that 'eycloud' scroll requires that you have one of the SQL DB scrolls and one of the app server scrolls

https://github.com/drnic/appscrolls/blob/master/scrolls/eycloud.rb#L9-23

'heroku' scroll could do a similar thing and check for incompatible scrolls.

If this is the solution, we could then add a metadata property "incompatible" which could allow a scroll to list what it is incompatible with?

Craig S. Cottingham added 2 commits April 13, 2012 22:10
Signed-off-by: Craig S. Cottingham <craig.cottingham@hrworx.com>
@krisalyssa
Copy link
Author

I think, for this case at least, the “exclusive” config key would suffice. I have added code to the heroku scroll which requires the postgresql scroll. If you add both the postgresql and mysql scrolls, an error should be presented because they both have “exclusive: orm”.

…except “exclusive” doesn’t appear to do anything at the moment. I’ll look into doing something about that and put it in a different pull request.

@drnic
Copy link
Owner

drnic commented Apr 14, 2012

The behavior from "exclusive: orm" is in http://github.com/intridea/rails_wizard.web. I don't think it currently has a meaning in rails_wizard/appscrolls CLIs. I could do though - perhaps show a warning or error?

@krisalyssa
Copy link
Author

Support for “exclusive” is in pull request #16.

@goshacmd
Copy link

You seem to create heroku apps on Bamboo. Just add --stack cedar option and change the domain in prompt from heroku.com to herokuapp.com.

Also, heroku works without PostgreSQL just fine, we can use MongoDB in our apps (so it would be cool if the scroll prompted for MongoDB addon — either MongoLab or MongoHQ, and added it to the app.)

@jackdempsey
Copy link
Contributor

Any status on this? Started to work on heroku today and just saw this.

My own $.02 regarding configuration, etc: it should do the simplest thing that could work for 80% cases. It seems close right now to being good enough to use. Couple other config options and we can get the scroll back into being usable, and iterate.

@krisalyssa
Copy link
Author

@jackdempsey: I agree re: the 80% solution, and thanks for reminding me of it. I had to put my contributions to appscrolls on the back burner for a couple of weeks, but I’m hoping to get back into it tomorrow.

@drnic
Copy link
Owner

drnic commented Apr 30, 2012

I think the bulk of the work will be in generating the correct Procfile. Should be easy - a scroll appends a line to the Procfile for its process (resque or unicorn, etc).

Suggestion - add a procfile scroll that Heroku uses - and detect scrolls?('procfile') instead of heroku. Procfiles are very nice and people use them outside of Heroku.

@krisalyssa
Copy link
Author

Procfiles aren’t strictly required by Heroku, right? In that case, the heroku scroll will need to look if the procfile scroll is included, rather than explicitly depending on it, I should think. Would that be the case with other scrolls as well (you mentioned resque and unicorn above, for instance)?

@drnic
Copy link
Owner

drnic commented Apr 30, 2012

If we can control the onboarding experience then we can setup a cedar stack for them. Why not do that?

Is bamboo stack better?

@jackdempsey
Copy link
Contributor

Cedar's definitely the way to go (IMHO). Push for latest version of ruby, rails, and support for other things like node, etc.

@drnic
Copy link
Owner

drnic commented Apr 30, 2012

Right; cedar isn't just about procfiles; its also a normal, old fashioned stack update.

I'm interested to start a "should we encourage/force ruby 1.9 for new apps" conversation too later.

@jackdempsey
Copy link
Contributor

Any updates on this? Would like to help get the heroku scroll to a place where it's usable, even if not hugely fully featured.

@drnic
Copy link
Owner

drnic commented May 13, 2012

Status:

I started a heroku branch with @hone. So far, a procfile scroll was added. The heroku scroll hasn't been upgraded to cedar; nor do any scrolls contribute the Procfile yet.

@jackdempsey
Copy link
Contributor

Cool! Feel free to shout if any little assistance is desired.

@hone
Copy link

hone commented May 24, 2012

Sorry, I was in Singapore or the last week. I hope to get working on this soon.

@jackdempsey
Copy link
Contributor

hey @hone still interested in this? I'm tired of forgetting about setting
config.assets.initialize_on_precompile = false every damn time + other things...Can I help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants