Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sets the new user up with an example set of agents #1404

Merged
merged 1 commit into from Apr 11, 2016

Conversation

TildeWill
Copy link
Contributor

  • gives them a place to start from
  • leverages existing code to import scenarios

I wanted to run this up the flag pole before I got too far, it still needs tests and there's a refactor in ScenarioImporter that I want to do. On Omniscope, I see a lot of users who are signing up but never create any agents. My hope is that if we give them some agents by default like the admin seed then people will be more likely to engage and modify their agents.

The weather agent is nice because it could be relevant to everyone (weather), but needs additional set up by the user (zip code and API key). Maybe that's a good thing because it gets new users involved and thinking about how to adapt it to their own needs?

@dsander
Copy link
Collaborator

dsander commented Apr 3, 2016

Great idea to utilize the scenario import for that! What do you think about using that approach for all new users that are created (either via the seeds, registration or the admin user interface)? We could have the default scenario match our current seeds.rb and make the path to the scenario JSON .envconfigurable (allowing HTTP URLs would be great for docker users).

@TildeWill TildeWill force-pushed the onboarding branch 4 times, most recently from 4238f16 to 655dfb5 Compare April 3, 2016 21:38
def self.import(user)
scenario_import = ScenarioImport.new()
scenario_import.set_user(user)
scenario_import.file = File.open(File.join(Rails.root, "data", "default_scenario.json"), "r")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we close this file afterwards?

@cantino
Copy link
Member

cantino commented Apr 4, 2016

I think it's a good idea! Probably should be a configuration option in .env if new users get this treatment or not.

@@ -54,6 +54,9 @@ def import_confirmed?
do_import == "1"
end

def import!(options = {})
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this method used anywhere?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it was the start of a refactor to have import check validity, the same way the ActiveRecord#save and #save! work. I've backed away from that change for the moment, but might go back to it

@TildeWill TildeWill force-pushed the onboarding branch 13 times, most recently from 1818cb1 to 6f3b676 Compare April 7, 2016 01:45
@TildeWill
Copy link
Contributor Author

@cantino I liked @dsander's suggestion that the Huginn admin can configure what file/URL to use as the import scenario, but I'm unsure about the ability to turn it off completely. What's the underlying concern? That there'd be a bunch of default agents using up CPU?

@TildeWill
Copy link
Contributor Author

I took a crack at using one ENV variable to control what file to use for the default scenario AND if you want the import at all. If it all looks good, then I think it's ready for merging.

scenario_file = ENV['DEFAULT_SCENARIO_FILE'] || File.join(Rails.root, "data", "default_scenario.json")
scenario_import.file = open(scenario_file)
raise "Import failed" unless scenario_import.valid? && scenario_import.import
scenario_import.file.close()
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe

ensure
  scenario_import.file.close

to also close the file when the import failed?

@dsander
Copy link
Collaborator

dsander commented Apr 7, 2016

but I'm unsure about the ability to turn it off completely. What's the underlying concern?

We always try to keep the default behavior the same as it was before a change. With no change to the .env file the scenario should only be imported for the seeded admin user. I think it would require an additional variable like IMPORT_DEFAULT_SCENARIO_FOR_ALL_USERS.

@TildeWill
Copy link
Contributor Author

Ready for review

@dsander
Copy link
Collaborator

dsander commented Apr 10, 2016

Very cool! Looks good to me, but waiting for another 👍 for confirm we did not miss anything :)

scenario_import = ScenarioImport.new()
scenario_import.set_user(user)
default_scenario = File.join(Rails.root, "data", "default_scenario.json")
scenario_file = ENV['DEFAULT_SCENARIO_FILE'] || default_scenario
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably be ENV['DEFAULT_SCENARIO_FILE'].presence || File.join(Rails.root, "data", "default_scenario.json") since '' is truthy.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, then it also guards agains an empty string, instead of just not being set. Thanks

@cantino
Copy link
Member

cantino commented Apr 10, 2016

Awesome! @dsander, is there an easy way for @TildeWill to test that this didn't mess up Docker upgrades in some way?

- gives them a place to start from
- leverages existing code to import scenarios
- adds test coverage to seeds to ensure sees can run multiple times against the same db as is the case for Docker
- adds env variable to set if importing is turned on for new user
- adds env variable to point to a custom scenario for new users
@dsander
Copy link
Collaborator

dsander commented Apr 10, 2016

With #1359 merged building docker images locally is possible with docker build --rm=true -t test/huginn -f docker/multi-process/Dockerfile ..

docker run --name huginn-test -it -p 3000:3000 test/huginn
<ctrl-c> after the container finished booting
docker start huginn-test
docker logs -f huginn-test

should ensure everything works. But I think the specs ensure, that running the seeds multiple times does not raise any exceptions.

@TildeWill
Copy link
Contributor Author

Docker seems to work just fine. Thanks for the instructions @dsander - I'm still very new to Docker

@cantino
Copy link
Member

cantino commented Apr 11, 2016

Awesome, LGTM too. Should we go ahead and merge?

@TildeWill
Copy link
Contributor Author

Sounds good to me.

On Sun, Apr 10, 2016 at 7:08 PM Andrew Cantino notifications@github.com
wrote:

Awesome, LGTM too. Should we go ahead and merge?


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#1404 (comment)

@dsander
Copy link
Collaborator

dsander commented Apr 11, 2016

That's a very neat addition, thanks @TildeWill!

@dsander dsander merged commit 15622e2 into huginn:master Apr 11, 2016
@TildeWill TildeWill deleted the onboarding branch May 18, 2016 03:32
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.

None yet

3 participants