json-spec 0.1.0 → 0.1.1
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.travis.yml +13 -0
- data/Gemfile +3 -0
- data/README.md +27 -26
- data/cachivache/.gitignore +1 -1
- data/cachivache/README.md +176 -96
- data/cachivache/Rakefile +18 -9
- data/cachivache/Vagrantfile +3 -3
- data/cachivache/cachivache.rb +4 -6
- data/cachivache/lib/rake-helper.rb +27 -105
- data/cachivache/lib/shell-contexts/shell-context.rb +63 -0
- data/cachivache/lib/shell-contexts/shell-exec.rb +19 -0
- data/cachivache/lib/shell-contexts/shell_buffer.rb +25 -0
- data/cachivache/lib/shell-contexts/shell_debugger.rb +11 -0
- data/cachivache/lib/{sh-file-context.rb → shell-file-context.rb} +13 -16
- data/cachivache/lib/shell-if-context.rb +21 -0
- data/cachivache/lib/stuff-api-behaviour.rb +145 -0
- data/cachivache/lib/stuff-configuration.rb +55 -0
- data/cachivache/lib/stuff-reminders-behaviour.rb +11 -0
- data/cachivache/stuff/ruby-json-spec.rb +10 -14
- data/json-spec.gemspec +4 -2
- data/lib/cabeza-de-termo/json-spec/expectations-library/default-expectations/default-expectations-mapping.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expectations-library/definition-builders/expectation-builders/expectations-definition-builder.rb +2 -2
- data/lib/cabeza-de-termo/json-spec/expectations-library/definition-builders/expectation-library-definition-builder.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expectations-library/definition-builders/modifier-builders/modifiers-definition-builder.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expectations-library/expectations-library.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expressions/json-any-of.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expressions/json-each-field.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expressions/json-each.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expressions/json-expression.rb +2 -2
- data/lib/cabeza-de-termo/json-spec/expressions/json-field.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expressions/json-list.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expressions/json-object.rb +1 -1
- data/lib/cabeza-de-termo/json-spec/expressions/json-spec.rb +4 -4
- data/lib/cabeza-de-termo/json-spec/version.rb +1 -1
- metadata +27 -21
- data/cachivache/lib/let-behaviour.rb +0 -27
- data/cachivache/lib/sh-if-context.rb +0 -31
- data/lib/cabeza-de-termo/json-spec/utilities/bind.rb +0 -20
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA1:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: d950cd2da7210e0edb2f3ae51e57a2649e9d913b
|
4
|
+
data.tar.gz: 65bbc08cf21a7d6d1f075311981061cc441cf4ef
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 82bec3c17230b4fc2e14f4c7b3ded8b4c52e985b87ae3ca15336a10b28af8b7f1fa73a39093b476fa94eaf89fa0439d7f6d557b228834c89b33e41aa10185795
|
7
|
+
data.tar.gz: cd0f955f2247a27ac9db51d2583c6217a5c045057955d1b54d3cc9ea8768add7158d20b6692bfd195eb4d54bf9a48a9f2be8019a290754408270fa7586f2ad50
|
data/.travis.yml
ADDED
data/Gemfile
CHANGED
data/README.md
CHANGED
@@ -2,6 +2,12 @@
|
|
2
2
|
|
3
3
|
A framework to declare expectations and verify that a json object satisfies those expectations. You can use this expectations to validate jsons you send or receive in your application, or to test your API with unit tests.
|
4
4
|
|
5
|
+
## Status
|
6
|
+
|
7
|
+
[![Gem Version](https://badge.fury.io/rb/json-spec.svg)](https://badge.fury.io/rb/json-spec)
|
8
|
+
[![Build Status](https://travis-ci.org/cabeza-de-termo/ruby-json-spec.svg?branch=master)](https://travis-ci.org/cabeza-de-termo/ruby-json-spec)
|
9
|
+
[![Coverage Status](https://coveralls.io/repos/cabeza-de-termo/ruby-json-spec/badge.svg?branch=master&service=github)](https://coveralls.io/github/cabeza-de-termo/ruby-json-spec?branch=master)
|
10
|
+
|
5
11
|
## Installation
|
6
12
|
|
7
13
|
Add this line to your application's Gemfile:
|
@@ -233,7 +239,7 @@ If you want to run this example, see the [second example](examples/example-2-def
|
|
233
239
|
|
234
240
|
## Declaring expectations for fields not known in advance.
|
235
241
|
|
236
|
-
If you run the previous example, you may notice that it outputs the
|
242
|
+
If you run the previous example, you may notice that it outputs the following:
|
237
243
|
|
238
244
|
```
|
239
245
|
- Failed expectations: 0
|
@@ -383,7 +389,7 @@ And third, and worst than the previous reasons, is that we are duplicating expec
|
|
383
389
|
|
384
390
|
So it would be nice to be able to organize the expectations somehow.
|
385
391
|
|
386
|
-
We can put expectations in methods, and then call those methods from within the json_spec. This methods can be in any
|
392
|
+
We can put expectations in methods, and then call those methods from within the json_spec. This methods can be in any object, but we are going to create a `ComposerJson` class to keep the `composer.json` expectations in one place.
|
387
393
|
So now we have the class
|
388
394
|
|
389
395
|
```ruby
|
@@ -505,13 +511,13 @@ CabezaDeTermo::JsonSpec::JsonSpec.new do
|
|
505
511
|
end
|
506
512
|
```
|
507
513
|
|
508
|
-
That is because when we don't pass a parameter to the defintion block, it changes the binding of self, and
|
514
|
+
That is because when we don't pass a parameter to the defintion block, it changes the binding of self, and then we can not declare thinkgs like
|
509
515
|
|
510
516
|
```ruby
|
511
517
|
.to_be_as_defined_in(self, :keywords_spec)
|
512
518
|
```
|
513
519
|
|
514
|
-
Changing the binding
|
520
|
+
Changing the binding of self without asking first is not a polite thing to do, but in the definition blocks of this framework it will only do that if no parameter is given to the block.
|
515
521
|
|
516
522
|
If you want to run this example, see the [fourth example](examples/example-4-to-be-as-defined-in.rb) in the `examples/` folder.
|
517
523
|
|
@@ -519,16 +525,18 @@ If you want to run this example, see the [fourth example](examples/example-4-to-
|
|
519
525
|
|
520
526
|
If we look at the `composer.json` definition, we will notice that sometimes it accepts different structures for the same field. For instance, for `psr-4` values, it can take a list of folder strings or a single folder string.
|
521
527
|
|
522
|
-
To expect different structures on the same object, we use
|
528
|
+
To expect different structures on the same object, we use `expect(:any_of)`:
|
523
529
|
|
524
530
|
```ruby
|
525
531
|
expect('psr-4') .to_be_a(:list) do
|
526
|
-
|
527
|
-
|
528
|
-
|
529
|
-
|
530
|
-
|
531
|
-
|
532
|
+
each do
|
533
|
+
expect(:any_of) do
|
534
|
+
expect_a(:scalar) .to_be_folder
|
535
|
+
or_also
|
536
|
+
expect_a(:list) .not_empty do
|
537
|
+
each do
|
538
|
+
expect_a(:scalar) .to_be_folder
|
539
|
+
end
|
532
540
|
end
|
533
541
|
end
|
534
542
|
end
|
@@ -672,7 +680,7 @@ CabezaDeTermo::JsonSpec::ExpectationsLibrary.define do
|
|
672
680
|
expectations do
|
673
681
|
define :to_be_some_complex_stuff do
|
674
682
|
with_class IsSomeComplexStuff
|
675
|
-
message "<%= value %> is not
|
683
|
+
message "<%= value %> is not some complex stuff."
|
676
684
|
end
|
677
685
|
end
|
678
686
|
end
|
@@ -710,7 +718,7 @@ json_spec.define do
|
|
710
718
|
end
|
711
719
|
```
|
712
720
|
|
713
|
-
You have to admit that these custom messages, although they are in a slang so boring and outdated that will get you to sleep in, like, 10 minutes, have a lot more of what we might call
|
721
|
+
You have to admit that these custom messages, although they are in a slang so boring and outdated that will get you to sleep in, like, 10 minutes, have a lot more of what we might call poetic flight than the default ones.
|
714
722
|
|
715
723
|
Just like when defining new Expectations, we have several ways to define custom messages. Lets walk through them:
|
716
724
|
|
@@ -726,7 +734,7 @@ CabezaDeTermo::JsonSpec::ExpectationsLibrary.define do
|
|
726
734
|
end
|
727
735
|
```
|
728
736
|
|
729
|
-
This is the simpliest way, and it should be enough most of the times. You can reference :value_holder, :value, :accessors_chain, :field and :expectation objects from within a erb block: `<%=
|
737
|
+
This is the simpliest way, and it should be enough most of the times. You can reference :value_holder, :value, :accessors_chain, :field and :expectation objects from within a erb block: `<%= ... %>`.
|
730
738
|
|
731
739
|
- Using a [BlockMessageFormatter](lib/cabeza-de-termo/json-spec/message-formatters/block-message-formatter.rb) object
|
732
740
|
|
@@ -734,7 +742,7 @@ This is the simpliest way, and it should be enough most of the times. You can re
|
|
734
742
|
CabezaDeTermo::JsonSpec::ExpectationsLibrary.define do
|
735
743
|
expectations do
|
736
744
|
define :to_be_integer do
|
737
|
-
message_block { |expectation, value_holder| "
|
745
|
+
message_block { |expectation, value_holder| "Not a valid integer." }
|
738
746
|
end
|
739
747
|
end
|
740
748
|
end
|
@@ -787,7 +795,7 @@ Ok, so we can define default expectations for each expression, add new custom ex
|
|
787
795
|
|
788
796
|
In that case, it is a good idea to bundle it all together in one place.
|
789
797
|
|
790
|
-
That place can be
|
798
|
+
That place can be a [LibraryInitializer](lib/cabeza-de-termo/json-spec/expectations-library/initializers/library-initializer.rb).
|
791
799
|
|
792
800
|
Create you own class that implements the [LibraryInitializer](lib/cabeza-de-termo/json-spec/expectations-library/initializers/library-initializer.rb) protocol, and there create a new and fully configured [ExpectationsLibrary](lib/cabeza-de-termo/json-spec/expectations-library/expectations-library.rb).
|
793
801
|
|
@@ -926,7 +934,7 @@ Anyways, you can use the Vagrant configuration for that. To do so:
|
|
926
934
|
|
927
935
|
* Install [VirtualBox](https://www.virtualbox.org/)
|
928
936
|
* Install [Vagrant](https://www.vagrantup.com/)
|
929
|
-
* `git clone --recursive git@github.com:
|
937
|
+
* `git clone --recursive git@github.com:cabeza-de-termo/ruby-json-spec.git`
|
930
938
|
* `cd ruby-json-spec/cachivache`
|
931
939
|
* `vagrant up`
|
932
940
|
|
@@ -935,7 +943,7 @@ and that will install all the necessary things to run the tests and examples in
|
|
935
943
|
Then to start playing around with the code, do
|
936
944
|
|
937
945
|
* `vagrant ssh`
|
938
|
-
* `cd src
|
946
|
+
* `cd src`
|
939
947
|
|
940
948
|
and that's it. You have a fully prepared, ready to use development environment.
|
941
949
|
|
@@ -943,16 +951,9 @@ and that's it. You have a fully prepared, ready to use development environment.
|
|
943
951
|
|
944
952
|
* `rake test`
|
945
953
|
|
946
|
-
## Development
|
947
|
-
|
948
|
-
After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
|
949
|
-
|
950
|
-
To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
|
951
|
-
|
952
954
|
## Contributing
|
953
955
|
|
954
|
-
Bug reports and pull requests are welcome on GitHub at https://github.com/
|
955
|
-
|
956
|
+
Bug reports and pull requests are welcome on GitHub at https://github.com/cabeza-de-termo/ruby-json-spec.
|
956
957
|
|
957
958
|
## License
|
958
959
|
|
data/cachivache/.gitignore
CHANGED
@@ -1 +1 @@
|
|
1
|
-
.vagrant
|
1
|
+
.vagrant
|
data/cachivache/README.md
CHANGED
@@ -1,6 +1,12 @@
|
|
1
1
|
# CabezaDeTermo::Cachivache
|
2
2
|
|
3
|
-
|
3
|
+
## Installation
|
4
|
+
|
5
|
+
- `gem install cachivache`
|
6
|
+
|
7
|
+
## Description
|
8
|
+
|
9
|
+
Cachivache is a provisioner for Vagrant machines with Ubuntu images.
|
4
10
|
|
5
11
|
You can provision a Vagrant VM using shell scripts, or more sophisticated tools like [Puppet](https://puppetlabs.com/), [Chef](https://www.chef.io/chef/), [salt](https://docs.saltstack.com/en/latest/), [Ansible](http://www.ansible.com/) and by the time you are reading this probably a few more.
|
6
12
|
|
@@ -16,24 +22,46 @@ On the other hand, the problems with shell provisions are that
|
|
16
22
|
|
17
23
|
The provisioning tools like Puppet and Chef resolve these problems, and a lot more. Actually, they resolve so much more problems that is overkill to only use them to provision a Vagrant machine for developing.
|
18
24
|
All of these tools define their own DSL and high level concepts and metaphors, they require you configure them, you must search for the correct recipes to install what you want, etc.
|
19
|
-
These tools are a must to manage the provisioning of different environments, but for a developer machine they are way too much.
|
25
|
+
These tools are a must to manage the provisioning of different environments, but for a single developer machine they are way too much.
|
20
26
|
|
21
27
|
Cachivache is a middle ground between bash scripts and these tools.
|
22
28
|
Instead of reinventing the wheel with a brand new DSL and new metaphors, Cachivache uses a wheel that we have had for ages: [Rake](https://github.com/ruby/rake).
|
23
29
|
|
24
|
-
|
30
|
+
## Usage
|
31
|
+
|
32
|
+
Once you installed the `cachivache` gem, setup cachivache for your project:
|
33
|
+
|
34
|
+
- Go to the root of your project
|
35
|
+
- `cachivache init`
|
36
|
+
- `cd cachivache`
|
37
|
+
|
38
|
+
write some stuffs in your `stuff` folder and set what stuff to install and your git email and user:
|
39
|
+
|
40
|
+
- `cachivache config`
|
41
|
+
|
42
|
+
and that's it, you can now start Vagrant with:
|
43
|
+
|
44
|
+
- `vagrant up`
|
45
|
+
- `vagrant ssh`
|
46
|
+
- `cd src`
|
47
|
+
|
48
|
+
and you have your project running in a Vagrant machine.
|
49
|
+
|
50
|
+
If you want to commit from Vagrant, add the `:'projects-setup'` as a dependency of your project in the stuff you created, it will set your git credentials.
|
51
|
+
|
52
|
+
The idea behind Cachivache is to put little bash scripts in Rake tasks, and then run those tasks from within the Vagrant VM. As the Ubuntu images already come with a Ruby installation, there's not much to do at all.
|
25
53
|
|
26
54
|
So, Cachivache has very few concepts:
|
27
55
|
|
28
56
|
- Bash scripts, which you put in Rake tasks
|
29
57
|
|
30
|
-
- Rake tasks, that can depend on other Rake tasks
|
58
|
+
- Rake tasks (also called stuffs in this framework), that can depend on other Rake tasks
|
31
59
|
|
32
60
|
- Ruby string interpolation, which allows you to easily parametrize stuff in the bash scripts
|
33
61
|
|
34
62
|
- And the secret ingredient: stuff
|
35
63
|
|
36
|
-
What is stuff? Stuff is a folder. That's it. Cachivache believes in giving power to the people, so instead of defining how, where and when you must organize your scripts, it will let you organize things in any way you want in a couple of folders: `stuff-library` and `stuff`. No recipes, playbooks, roles, bags, configurations, minions, masters, slaves, facts, etc. Just put stuff in a folder.
|
64
|
+
What is stuff? Stuff is a folder with .rb files. That's it. Cachivache believes in giving power to the people, so instead of defining how, where and when you must organize your scripts, it will let you organize things in any way you want in a couple of folders: `stuff-library` and `stuff`. No recipes, playbooks, roles, bags, configurations, minions, masters, slaves, facts, etc. Just put stuff in a folder.
|
37
65
|
[`stuff-library`](https://github.com/cabeza-de-termo/stuff-library) folder holds some existing stuff you can use to install things, and in `stuff` you can toss your own stuff for your project.
|
38
66
|
|
39
67
|
## So, what does a stuff look like?
|
@@ -43,200 +71,252 @@ Well, here's an example stuff that setups all the necessary things to work on a
|
|
43
71
|
```ruby
|
44
72
|
dependencies = [
|
45
73
|
:'projects-setup',
|
46
|
-
|
74
|
+
:graphviz,
|
47
75
|
:xdebug,
|
48
|
-
:
|
76
|
+
:'php-cli',
|
77
|
+
:composer,
|
49
78
|
]
|
50
79
|
|
51
|
-
|
52
|
-
|
53
|
-
|
54
|
-
cd #{PHPJsonSpec.project_folder}
|
80
|
+
stuff :'php-json-spec' => dependencies do
|
81
|
+
shell %{
|
82
|
+
cd #{PhpJsonSpec.project_folder}
|
55
83
|
|
56
|
-
|
84
|
+
composer install
|
57
85
|
|
58
|
-
|
59
|
-
|
86
|
+
# Run the test coverage report
|
87
|
+
php vendor/bin/phpunit -c phpunit-with-coverage.xml
|
60
88
|
|
61
|
-
|
62
|
-
|
63
|
-
|
64
|
-
end
|
89
|
+
# Generate the documentation
|
90
|
+
php vendor/bin/phpdoc
|
91
|
+
}
|
65
92
|
end
|
66
93
|
|
67
|
-
|
68
|
-
include LetBehaviour
|
69
|
-
|
94
|
+
configure :PhpJsonSpec do
|
70
95
|
let(:project_folder) { Cachivache.src_folder }
|
71
96
|
end
|
72
97
|
```
|
98
|
+
## How do I tell Cachivache what to install?
|
99
|
+
|
100
|
+
Edit the file `cachivache.rb` and define the stuffs to install in the section
|
101
|
+
|
102
|
+
```ruby
|
103
|
+
####################################
|
104
|
+
# Define what stuff to install
|
105
|
+
####################################
|
106
|
+
|
107
|
+
let(:stuff_to_install) {
|
108
|
+
[
|
109
|
+
'ruby-json-spec',
|
110
|
+
'some-other-stuff',
|
111
|
+
'a-namespace:and-another-one:more-stuff',
|
112
|
+
'mysql-server', # You can install any stuff as long as it is defined
|
113
|
+
]
|
114
|
+
}
|
115
|
+
```
|
73
116
|
|
74
|
-
|
117
|
+
Note that if you set the dependencies of each stuff correctly, you will only have to tell Cachivache to install the top most stuff, and Rake will do the rest for you. Thanks Rake!
|
75
118
|
|
76
119
|
## What other awesome features has Cachivache?
|
77
120
|
|
78
121
|
As I said before, all the work is done by Rake, so pretty much none.
|
79
122
|
|
80
|
-
There is some sintactic sugar you can use to perform some common task though.
|
123
|
+
There is some sintactic sugar you can use to perform some common task though. But please note that using any of these shorcuts is not mandatory at all, you can just stick to plain old shell scripts.
|
81
124
|
|
82
125
|
If you haven't see any ruby code before, here are some tips to use in Cachivache stuffs:
|
83
126
|
|
84
127
|
### You can define strings in several ways:
|
85
128
|
|
86
129
|
```ruby
|
87
|
-
|
88
|
-
|
130
|
+
stuff :'do-stuff' do
|
131
|
+
shell %Q{
|
89
132
|
echo "stuff"
|
90
133
|
}
|
91
134
|
end
|
92
135
|
|
93
136
|
# or
|
94
137
|
|
95
|
-
|
96
|
-
|
138
|
+
stuff :'do-stuff' do
|
139
|
+
shell %Q[
|
97
140
|
echo "stuff"
|
98
141
|
]
|
99
142
|
end
|
100
143
|
|
101
144
|
# or
|
102
145
|
|
103
|
-
|
104
|
-
|
146
|
+
stuff :'do-stuff' do
|
147
|
+
shell %(
|
105
148
|
echo "stuff"
|
106
149
|
)
|
107
150
|
end
|
108
151
|
|
109
152
|
# or in a single line
|
110
153
|
|
111
|
-
|
112
|
-
|
154
|
+
stuff :'do-stuff' do
|
155
|
+
shell %Q{echo "stuff"}
|
113
156
|
end
|
114
157
|
|
115
158
|
# or with ""
|
116
159
|
|
117
|
-
|
118
|
-
|
160
|
+
stuff :'do-stuff' do
|
161
|
+
shell "echo \"stuff\""
|
119
162
|
end
|
120
163
|
```
|
121
164
|
|
122
165
|
You see in the last example that if we define strings using "" we need to scape internals \", so the simpliest is to use `%Q{}`.
|
123
166
|
|
124
|
-
### You can call as many `
|
167
|
+
### You can call as many `shell` blocks within a task as you like. You can also :invoke and :execute other tasks:
|
125
168
|
|
126
169
|
```ruby
|
127
|
-
|
128
|
-
|
170
|
+
stuff :'do-stuff' do
|
171
|
+
shell %Q{
|
129
172
|
echo "stuff"
|
130
173
|
}
|
131
174
|
|
132
|
-
|
175
|
+
invoke 'install-apache'
|
176
|
+
|
177
|
+
shell %Q{
|
133
178
|
echo "even more stuff"
|
134
179
|
}
|
135
|
-
end
|
136
|
-
```
|
137
180
|
|
138
|
-
|
181
|
+
execute 'restart-apache'
|
139
182
|
|
140
|
-
|
141
|
-
|
142
|
-
|
143
|
-
execute 'restart-apache'
|
183
|
+
shell! %Q{
|
184
|
+
echo "You would normally not need to use :shell! (note the exclamation mark) but you can"
|
185
|
+
}
|
144
186
|
end
|
145
187
|
```
|
146
188
|
|
147
189
|
The difference between :invoke and :execute is that :execute will perform the task every time it's called, whilst :invoke will only run the task once during the provision. So, to install and configure stuff use :invoke, but to turn things on and off use :execute.
|
148
|
-
Or always use :execute to make things simplier. It's up to you.
|
190
|
+
Or if your tasks are idempotent, always use :execute to make things simplier. It's up to you.
|
149
191
|
|
150
192
|
### Instead of using bash `if ! ...; then; .... fi`, you can use these Cachivache helpers:
|
151
193
|
|
152
194
|
```ruby
|
153
|
-
|
154
|
-
|
155
|
-
|
156
|
-
|
157
|
-
|
158
|
-
|
159
|
-
|
195
|
+
stuff :'do-stuff' do
|
196
|
+
shell_unless file_exists: '/bla.conf' do
|
197
|
+
shell %Q{
|
198
|
+
ls -la
|
199
|
+
rm -rf bla
|
200
|
+
}
|
201
|
+
end
|
160
202
|
end
|
161
203
|
```
|
162
204
|
|
163
205
|
```ruby
|
164
|
-
|
165
|
-
|
166
|
-
|
167
|
-
|
168
|
-
|
169
|
-
|
170
|
-
|
206
|
+
stuff :'do-stuff' do
|
207
|
+
shell_unless folder_exists: '/bla' do
|
208
|
+
shell %Q{
|
209
|
+
ls -la
|
210
|
+
rm -rf bla
|
211
|
+
}
|
212
|
+
end
|
171
213
|
end
|
172
214
|
```
|
173
215
|
|
174
216
|
```ruby
|
175
|
-
|
176
|
-
|
177
|
-
|
178
|
-
|
179
|
-
|
180
|
-
|
181
|
-
|
217
|
+
stuff :'do-stuff' do
|
218
|
+
shell_unless file: '/bla', contains: 'some regex' do
|
219
|
+
shell %Q{
|
220
|
+
ls -la
|
221
|
+
rm -rf bla
|
222
|
+
}
|
223
|
+
end
|
182
224
|
end
|
183
225
|
```
|
184
226
|
|
185
227
|
```ruby
|
186
|
-
|
187
|
-
|
188
|
-
|
189
|
-
|
190
|
-
|
191
|
-
|
192
|
-
|
228
|
+
stuff :'do-stuff' do
|
229
|
+
shell_unless command: 'java -version', contains: 'java 1.8' do
|
230
|
+
shell %Q{
|
231
|
+
ls -la
|
232
|
+
rm -rf bla
|
233
|
+
}
|
234
|
+
end
|
193
235
|
end
|
194
236
|
```
|
195
237
|
|
196
238
|
- To append and replace text in a file, you can use this Cachivache helper:
|
197
239
|
|
198
240
|
```ruby
|
199
|
-
|
200
|
-
|
201
|
-
|
241
|
+
stuff :'do-stuff' do
|
242
|
+
in_file "/etc/bla.conf" do
|
243
|
+
shell replace pattern: "%user%", with: "admin"
|
202
244
|
|
203
|
-
|
204
|
-
|
205
|
-
|
245
|
+
shell append "[cachivache]"
|
246
|
+
shell append "path='/bla'"
|
247
|
+
shell append :new_line
|
248
|
+
end
|
249
|
+
end
|
250
|
+
```
|
251
|
+
|
252
|
+
### You can use variables instead of hardcoding values in the scripts:
|
253
|
+
|
254
|
+
```ruby
|
255
|
+
stuff :'do-stuff' do
|
256
|
+
shell %Q{
|
257
|
+
mkdir #{DoStuff.some_folder}
|
258
|
+
|
259
|
+
mkdir #{SomethingDefinedElsewhereWorksToo.some_folder}
|
260
|
+
}
|
261
|
+
end
|
262
|
+
|
263
|
+
configure :DoStuff do
|
264
|
+
let(:some_folder) { '/home/vagrant/some-folder' }
|
206
265
|
end
|
207
266
|
```
|
208
267
|
|
209
268
|
### If you want to remind the user of something after the provision is done, in any task use :remind_to
|
210
269
|
|
211
270
|
```ruby
|
212
|
-
|
213
|
-
|
214
|
-
|
215
|
-
|
271
|
+
stuff :'do-stuff' do
|
272
|
+
shell %Q{
|
273
|
+
ls -la
|
274
|
+
}
|
216
275
|
|
217
|
-
|
276
|
+
remind_to "Please don't forget to add '#{Cachivache.vagrant_ip_address} cachivache.com' to your /etc/hosts file"
|
218
277
|
end
|
219
278
|
```
|
279
|
+
## What if I want to use my own [`stuff-library`](https://github.com/cabeza-de-termo/stuff-library)?
|
220
280
|
|
221
|
-
|
281
|
+
No prob! Go to your `cachivache` folder and:
|
222
282
|
|
223
|
-
-
|
224
|
-
- `git clone git@github.com:cabeza-de-termo/cachivache.git`
|
225
|
-
- `cd cachivache/`
|
226
|
-
- `rm -rf .git/`
|
227
|
-
- `git submodule add git@github.com:cabeza-de-termo/stuff-library.git`
|
283
|
+
- `cachivache add-stuff-library git@github.com:someuser/my-very-own-stuff-library.git`
|
228
284
|
|
229
|
-
|
285
|
+
Cachivache will load any .rb file in the cachivache folder, so your library stuff will be loaded too.
|
230
286
|
|
231
|
-
|
287
|
+
To update some stuff library from git do:
|
232
288
|
|
233
|
-
|
289
|
+
- `cachivache update-stuff-libraries my-very-own-stuff-library`
|
234
290
|
|
235
|
-
|
291
|
+
To update all the stuff libraries do:
|
236
292
|
|
237
|
-
- `
|
293
|
+
- `cachivache update-stuff-libraries`
|
238
294
|
|
239
|
-
|
295
|
+
To remove a stuff library do:
|
296
|
+
|
297
|
+
- `cachivache remove-stuff-libraries stuff-library`
|
298
|
+
|
299
|
+
## Debugging
|
300
|
+
|
301
|
+
During the building of the stuff, it's useful to be able to see what the provision would do instead of running it.
|
302
|
+
|
303
|
+
To debug the provision do
|
304
|
+
|
305
|
+
- Go to the root of your project
|
306
|
+
- `cd cachivache`
|
307
|
+
- `vagrant ssh`
|
308
|
+
- `cd src/cachivache` (now you are in Vagrant)
|
309
|
+
- `bundle install`
|
310
|
+
- `rake explain` will output the complete shell script without running it
|
311
|
+
- `rake some-stuff` will execute only some-stuff and its dependencies
|
312
|
+
|
313
|
+
## Running the tests
|
314
|
+
|
315
|
+
Not a single test was written this day :(
|
316
|
+
|
317
|
+
## Roadmap
|
318
|
+
|
319
|
+
- v1.0.0: Make a custom Vagrant provisioner plugin
|
240
320
|
|
241
321
|
## Contributing
|
242
322
|
|