README.md in gush-0.1.2 vs README.md in gush-0.2.0
- old
+ new
@@ -61,11 +61,11 @@
#### Passing parameters to jobs
You can pass any primitive arguments into jobs while defining your workflow:
```ruby
-# workflows/sample_workflow.rb
+# app/workflows/sample_workflow.rb
class SampleWorkflow < Gush::Workflow
def configure
run FetchJob1, params: { url: "http://some.com/url" }
end
end
@@ -76,11 +76,12 @@
#### Defining jobs
Jobs are classes inheriting from `Gush::Job`:
```ruby
-class FetchJob1 < Gush::Job
+# app/jobs/fetch_job.rb
+class FetchJob < Gush::Job
def work
# do some fetching from remote APIs
params #=> {url: "http://some.com/url"}
end
@@ -95,11 +96,11 @@
`configure` method.
Here's an example of a workflow responsible for publishing a book:
```ruby
-# workflows/sample_workflow.rb
+# app/workflows/sample_workflow.rb
class PublishBookWorkflow < Gush::Workflow
def configure(url, isbn)
run FetchBook, params: { url: url }
run PublishBook, params: { book_isbn: isbn }
end
@@ -180,11 +181,11 @@
```
`payloads` is a hash containing outputs from all parent jobs, where job class names are the keys.
**Note:** `payloads` will only contain outputs of the job's ancestors. So if job `A` depends on `B` and `C`,
-the `paylods` hash will look like this:
+the `payloads` hash will look like this:
```ruby
{
"B" => (...),
"C" => (...)
@@ -197,11 +198,11 @@
#### In Ruby:
```ruby
flow.reload
flow.status
-#=> :running|:pending|:finished|:failed
+#=> :running|:finished|:failed
```
`reload` is needed to see the latest status, since workflows are updated asynchronously.
#### Via CLI:
@@ -237,10 +238,10 @@
- [Mateusz Lenik](https://github.com/mlen)
- [Michał Krzyżanowski](https://github.com/krzyzak)
## Contributing
-1. Fork it ( http://github.com/pokonski/gush/fork )
+1. Fork it ( http://github.com/chaps-io/gush/fork )
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create new Pull Request