dpl 1.9.6.travis.2785.5 → 1.9.6.travis.2786.5
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.github/CONTRIBUTING.md +137 -0
- data/Rakefile +3 -2
- data/lib/dpl/version.rb +1 -1
- metadata +1 -1
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: 2aeed418eee48c5a1f70a183f440c3ed80b9a662a964c95ec10f71174b88ce32
|
4
|
+
data.tar.gz: ee5e06a0298a164e29dd9f1b10574d2a54c68c8276d7f136e4646fde8a9ec9a3
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 62327c030d2b5d097b5884489a397b7a7ab3ecf321ef156c4cc30120bd7098febb348f380401d3b102cafc30ba08cc8e4a3309fab8028c721ac554383f3d8510
|
7
|
+
data.tar.gz: 9646f491985263caeb816b65bca8258e9a71d98fbd07fee4c0508588dcc5c3b8a9bafc22ce6dfeced760bf498a79a0d59f29692dd785ddbb8c5fe5c6d2570484
|
data/.github/CONTRIBUTING.md
CHANGED
@@ -1,3 +1,140 @@
|
|
1
|
+
# Writing a new deployment provider
|
2
|
+
|
3
|
+
So you want to add a new deployment provider,
|
4
|
+
fix a bug, or add a new feature to an
|
5
|
+
existing provider.
|
6
|
+
|
7
|
+
That's great.
|
8
|
+
|
9
|
+
This document explains what you need to know in order
|
10
|
+
to accomplish the goal.
|
11
|
+
|
12
|
+
`dpl` is written in Ruby, and we assume that you have
|
13
|
+
a good understanding of how it works.
|
14
|
+
|
15
|
+
## General structure of the `dpl` code base
|
16
|
+
|
17
|
+
### `lib/dpl/provider`
|
18
|
+
|
19
|
+
Each provider code is a subclass of `DPL::Provider`,
|
20
|
+
and it lives under `lib/dpl/provider`.
|
21
|
+
|
22
|
+
```
|
23
|
+
lib
|
24
|
+
└── dpl
|
25
|
+
├── cli.rb
|
26
|
+
├── error.rb
|
27
|
+
├── provider
|
28
|
+
│ ├── anynines.rb
|
29
|
+
│ ├── atlas.rb
|
30
|
+
│ ├── azure_webapps.rb
|
31
|
+
│ ├── bintray.rb
|
32
|
+
│ ├── bitballoon.rb
|
33
|
+
│ ├── ⋮
|
34
|
+
```
|
35
|
+
|
36
|
+
`dpl` script will receive the provider name via `--provider`
|
37
|
+
command-line option; e.g.,
|
38
|
+
|
39
|
+
dpl --provider=script …
|
40
|
+
|
41
|
+
and attempts to load it at run time.
|
42
|
+
|
43
|
+
In order to make `dpl` be aware of a provider code, put the provider
|
44
|
+
code in `lib/dpl/provider` and add a key-value pair to the `DPL::Provider::GEM_NAME_OF`
|
45
|
+
hash in `lib/dpl/provider.rb`.
|
46
|
+
|
47
|
+
For example:
|
48
|
+
|
49
|
+
```ruby
|
50
|
+
module DPL
|
51
|
+
class Provider
|
52
|
+
GEM_NAME_OF = {
|
53
|
+
'NewProvider' => 'new_provider',
|
54
|
+
}
|
55
|
+
end
|
56
|
+
end
|
57
|
+
```
|
58
|
+
|
59
|
+
There is no standard for how the key and value are defined, but
|
60
|
+
we generally recommend adhering to the snake-case naming;
|
61
|
+
e.g., for the `CloudFoundry` class, the file (and the gem name) is
|
62
|
+
`cloud_foundry`.
|
63
|
+
(Please note that some existing provider codes violate this guideline.)
|
64
|
+
|
65
|
+
#### Basic structure of the provider code
|
66
|
+
|
67
|
+
When `dpl` loads the provider code, first it sets up dependencies
|
68
|
+
(install `apt` packages, `npm` modules, etc.).
|
69
|
+
|
70
|
+
Then the following methods on the provider code are invoked:
|
71
|
+
|
72
|
+
1. `#check_auth`: sets up (and ideally verifies) user credentials
|
73
|
+
1. `#check_app`: verify that the application is valid
|
74
|
+
1. `#push_app`: deploy the code
|
75
|
+
|
76
|
+
If you are trying to implement support for a new provider and this basic
|
77
|
+
flow does not suit your needs, be sure to seek help/advice.
|
78
|
+
|
79
|
+
### `spec/provider`
|
80
|
+
|
81
|
+
`dpl` uses [RSpec](https://github.com/rspec) for tests.
|
82
|
+
The specs reside in `spec/provider`, and each provider has the corresponding
|
83
|
+
`*_spec.rb` file to hold specs.
|
84
|
+
|
85
|
+
## Testing new code locally
|
86
|
+
|
87
|
+
To test it locally, first you need to write a corresponding `dpl-*.gemspec` file.
|
88
|
+
You can write this file from scratch, or use the `gemspec_for` helper
|
89
|
+
method, found in `gemspec_helper.rb`.
|
90
|
+
We recommend the helper to ensure consistency.
|
91
|
+
The important thing is that your new gem has a good runtime dependency, most
|
92
|
+
notably on `dpl`.
|
93
|
+
|
94
|
+
Once you have `dpl-*.gemspec`, you are ready to run specs. To do this,
|
95
|
+
call `spec-*` Rake task.
|
96
|
+
|
97
|
+
> This task (and others) are dynamically inferred from the presence of `dpl-*.gemspec`,
|
98
|
+
> so there is no need for you to touch `Rakefile`.
|
99
|
+
|
100
|
+
This Rake task builds and installs `dpl` and the provider gem from the local source,
|
101
|
+
installs dependencies and runs the specs in `spec/provider/*_spec.rb`.
|
102
|
+
For example, to run specs on the `s3` provider:
|
103
|
+
|
104
|
+
$ bundle install
|
105
|
+
$ rake spec-s3
|
106
|
+
|
107
|
+
If you have other versions of `dpl` and `dpl-*` gems before running the Rake task,
|
108
|
+
they may interfere with your tests.
|
109
|
+
|
110
|
+
If you suspect this interference, be sure to uninstall them by
|
111
|
+
|
112
|
+
$ gem uninstall -aIx dpl dpl-* # for appropriate provider(s)
|
113
|
+
|
114
|
+
or
|
115
|
+
|
116
|
+
$ rake clean
|
117
|
+
|
118
|
+
to completely clean up the working directory.
|
119
|
+
|
120
|
+
### Testing a portion of specs
|
121
|
+
|
122
|
+
The `spec-*` Rake tasks take an optional argument, which is passed on
|
123
|
+
to `rspec` to indicate which lines to execute.
|
124
|
+
|
125
|
+
For example:
|
126
|
+
|
127
|
+
$ rake spec-s3["55"]
|
128
|
+
|
129
|
+
### Avoid making actual network calls
|
130
|
+
|
131
|
+
Deployment code often interact with external services to do the job.
|
132
|
+
It is tempting to make calls to external servers during the specs,
|
133
|
+
but resist this temptation.
|
134
|
+
Instead, mock the network calls and write specs that deal with different results.
|
135
|
+
Assuming that the external resources are stable in their behavior,
|
136
|
+
this will make the specs less susceptible to network issues.
|
137
|
+
|
1
138
|
# Testing `dpl` in the context of Travis CI builds
|
2
139
|
|
3
140
|
It is possible to test new deployment provider or new functionality
|
data/Rakefile
CHANGED
@@ -164,12 +164,13 @@ providers.each do |provider|
|
|
164
164
|
end
|
165
165
|
|
166
166
|
desc %Q(Run dpl-#{provider} specs)
|
167
|
-
task "spec-#{provider}" => [Rake::FileTask[dpl_bin], "Gemfile-#{provider}"] do
|
167
|
+
task "spec-#{provider}", [:lines] => [Rake::FileTask[dpl_bin], "Gemfile-#{provider}"] do |_t, args|
|
168
|
+
tail = args.lines ? ":#{args.lines}" : ""
|
168
169
|
sh "rm -f $HOME/.npmrc"
|
169
170
|
logger.info green("Running `bundle install` for #{provider}")
|
170
171
|
sh 'bash', '-cl', "bundle install --gemfile=Gemfile-#{provider} --path=vendor/cache/dpl-#{provider} --retry=3 --binstubs=stubs"
|
171
172
|
logger.info green("Running specs for #{provider}")
|
172
|
-
sh "env BUNDLE_GEMFILE=Gemfile-#{provider} ./stubs/rspec spec/provider/#{provider}_spec.rb"
|
173
|
+
sh "env BUNDLE_GEMFILE=Gemfile-#{provider} ./stubs/rspec spec/provider/#{provider}_spec.rb#{tail}"
|
173
174
|
end
|
174
175
|
|
175
176
|
desc "Build dpl-#{provider} gem"
|
data/lib/dpl/version.rb
CHANGED