heroku_hatchet 4.0.13 → 4.1.0
Sign up to get free protection for your applications and to get access to all the features.
- checksums.yaml +4 -4
- data/.github/workflows/check_changelog.yml +12 -0
- data/CHANGELOG.md +5 -0
- data/README.md +41 -51
- data/lib/hatchet/app.rb +16 -3
- data/lib/hatchet/test_run.rb +3 -0
- data/lib/hatchet/version.rb +1 -1
- data/test/hatchet/ci_too_test.rb +9 -1
- metadata +4 -3
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: cfb6c64e1ff612534d992f0c81cbf4f7e5aa24d23dcb83ec084b345a777f1c5e
|
4
|
+
data.tar.gz: 8f17c2ebb7bea2bcb22a27b1a134637a19e444a08ba5860db2f3dc344ae0203d
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
6
|
+
metadata.gz: 3816f55ea5995623c5067e08c473a12a8370e492d712de659b1b846287df77d87c841f91426dd2dec9fedd3f2fd27609871a777f6eb4d59875b0aaa9f2546878
|
7
|
+
data.tar.gz: c321280743113a3b2226f9329e8fb66deb03e82a6ea2389a620ce57b63789184f576792fbe6773d2be013a190833e29af4ae95078ac20dd71f299ac9e6f0aac1
|
@@ -0,0 +1,12 @@
|
|
1
|
+
name: Check Changelog
|
2
|
+
|
3
|
+
on: [pull_request]
|
4
|
+
|
5
|
+
jobs:
|
6
|
+
build:
|
7
|
+
runs-on: ubuntu-latest
|
8
|
+
steps:
|
9
|
+
- uses: actions/checkout@v1
|
10
|
+
- name: Check that CHANGELOG is touched
|
11
|
+
run: |
|
12
|
+
cat $GITHUB_EVENT_PATH | jq .pull_request.title | grep -i '\[\(\(changelog skip\)\|\(ci skip\)\)\]' || git diff remotes/origin/${{ github.base_ref }} --name-only | grep CHANGELOG.md
|
data/CHANGELOG.md
CHANGED
@@ -1,5 +1,10 @@
|
|
1
1
|
## HEAD
|
2
2
|
|
3
|
+
## 4.1.0
|
4
|
+
|
5
|
+
- Fix CI 403 errors caused by Heroku auto deleting pipelines that do not have an app attached (https://github.com/heroku/hatchet/pull/68)
|
6
|
+
- CI runs now default to `heroku-18` this is a breaking change (https://github.com/heroku/hatchet/pull/68)
|
7
|
+
|
3
8
|
## 4.0.13
|
4
9
|
|
5
10
|
- Introduce `App#in_directory_fork` for safe execution of code that might mutate the process env vars (https://github.com/heroku/hatchet/pull/65)
|
data/README.md
CHANGED
@@ -12,10 +12,9 @@ First run:
|
|
12
12
|
|
13
13
|
$ bundle install
|
14
14
|
|
15
|
-
This library uses the heroku CLI and API
|
16
|
-
available to the system. If you're running on a CI platform you'll need to generate an OAuth token and make it available on the system you're running on.
|
15
|
+
This library uses the heroku CLI and API. You will need to make your API key available to the system. If you're running on a CI platform, you'll need to generate an OAuth token and make it available on the system you're running on.
|
17
16
|
|
18
|
-
To get a token,
|
17
|
+
To get a token, install the https://github.com/heroku/heroku-cli-oauth#creating plugin. Then run:
|
19
18
|
|
20
19
|
```sh
|
21
20
|
$ heroku authorizations:create --description "For Travis"
|
@@ -27,7 +26,7 @@ Scope: global
|
|
27
26
|
Token: <token>
|
28
27
|
```
|
29
28
|
|
30
|
-
You'll set the `<token>` value to the `HEROKU_API_KEY` env var. For example
|
29
|
+
You'll set the `<token>` value to the `HEROKU_API_KEY` env var. For example, you could add it on Travis like this:
|
31
30
|
|
32
31
|
```sh
|
33
32
|
$ travis encrypt HEROKU_API_KEY=<token> --add
|
@@ -39,7 +38,7 @@ You'll also need an email address that goes with your token:
|
|
39
38
|
$ travis encrypt HEROKU_API_USER=<example@example.com> --add
|
40
39
|
```
|
41
40
|
|
42
|
-
If you're running locally, your system credentials will be pulled from `heroku auth:token
|
41
|
+
If you're running locally, your system credentials will be pulled from `heroku auth:token`.
|
43
42
|
|
44
43
|
You'll also need to trigger a "setup" step for CI tasks. You can do it on Travis CI like this:
|
45
44
|
|
@@ -68,36 +67,36 @@ and on Heroku CI like this:
|
|
68
67
|
|
69
68
|
## Why Test a Buildpack?
|
70
69
|
|
71
|
-
|
70
|
+
Testing a buildpack prevents regressions, and pushes out new features faster and easier.
|
72
71
|
|
73
72
|
## What can Hatchet Test?
|
74
73
|
|
75
|
-
Hatchet can easily test deployment of buildpacks, getting the build output, and running arbitrary interactive processes
|
74
|
+
Hatchet can easily test certain operations: deployment of buildpacks, getting the build output, and running arbitrary interactive processes (e.g. `heroku run bash`). Hatchet can also test running CI against an app.
|
76
75
|
|
77
76
|
## Writing Tests
|
78
77
|
|
79
|
-
Hatchet
|
78
|
+
Hatchet assumes a test framework doesn't exist. [This project](https://github.com/heroku/hatchet) uses `Test::Unit` to run it's own tests. While the [heroku-ruby-buildpack](https://github.com/heroku/heroku-buildpack-ruby) uses rspec.
|
80
79
|
|
81
|
-
|
80
|
+
Running `focused: true` in rspec allows you to choose which test to run and to tag tests. Rspec has useful plugins, such as `gem 'rspec-retry'` which will re-run any failed tests a given number of times (I recommend setting this to at least 2) to decrease false negatives in your tests.
|
82
81
|
|
83
|
-
Whatever testing framework you chose, we recommend using a parallel test runner when running the full suite [
|
82
|
+
Whatever testing framework you chose, we recommend using a parallel test runner when running the full suite. [Parallel_tests](https://github.com/grosser/parallel_tests) works with rspec and test::unit and is amazing.
|
84
83
|
|
85
|
-
If you're unfamiliar with the ruby testing eco-system or want some help, looking at existing projects
|
84
|
+
If you're unfamiliar with the ruby testing eco-system or want some help, start by looking at existing projects.
|
86
85
|
|
87
|
-
There is a section below on getting Hatchet to work on Travis.
|
86
|
+
*Spoilers: There is a section below on getting Hatchet to work on Travis.
|
88
87
|
|
89
88
|
## Testing a Buildpack
|
90
89
|
|
91
|
-
Hatchet was built for testing the Ruby buildpack, but
|
90
|
+
Hatchet was built for testing the Ruby buildpack, but Hatchet can test any buildpack provided your tests are written in Ruby.
|
92
91
|
|
93
92
|
You will need copies of applications that can be deployed by your buildpack. You can see the ones for the Hatchet unit tests (and the Ruby buildpack) https://github.com/sharpstone. Hatchet does not require that you keep these apps checked into your git repo which would make fetching your buildpack slow, instead declare them in a `hatchet.json` file (see below).
|
94
93
|
|
95
|
-
Hatchet will automate retrieving these files `$ hatchet install`,
|
94
|
+
Hatchet will automate retrieving these files `$ hatchet install`, deploy these files using your local copy of the buildpack, retrieve the build output and run commands against deploying applications.
|
96
95
|
|
97
96
|
|
98
97
|
## Hatchet.json
|
99
98
|
|
100
|
-
Hatchet expects a json file in the root of your buildpack called `hatchet.json`. You can configure install options using the `"hatchet"` key. In this example we're telling
|
99
|
+
Hatchet expects a json file in the root of your buildpack called `hatchet.json`. You can configure install options using the `"hatchet"` key. In this example, we're telling Hatchet to install the given repos to our `test/fixtures` directory instead of the default current directory.
|
101
100
|
|
102
101
|
```
|
103
102
|
{
|
@@ -122,7 +121,7 @@ test/
|
|
122
121
|
no_lockfile/
|
123
122
|
```
|
124
123
|
|
125
|
-
|
124
|
+
You can reference one of these applications in your test by using it's git name:
|
126
125
|
|
127
126
|
```ruby
|
128
127
|
Hatchet::Runner.new('no_lockfile')
|
@@ -130,26 +129,17 @@ Hatchet::Runner.new('no_lockfile')
|
|
130
129
|
|
131
130
|
If you have conflicting names, use full paths.
|
132
131
|
|
133
|
-
|
132
|
+
To test with fixtures that are checked in locally, add the fixture directory to the path and skip the `hatchet install`:
|
134
133
|
|
135
134
|
```
|
136
135
|
Hatchet::Runner.new("spec/fixtures/repos/node-10-metrics")
|
137
136
|
```
|
138
137
|
|
139
|
-
|
140
|
-
directory, if you're using a runner that looks for patterns such as
|
141
|
-
`*_test.rb` to run your hatchet tests, it may incorrectly think you want
|
142
|
-
to run the tests inside of the repos. To get rid of this
|
143
|
-
problem move your repos direcory out of `test/` or be more specific
|
144
|
-
with your tests such as moving them to a `test/hatchet` directory and
|
145
|
-
changing your pattern if you are using `Rake::TestTask` it might look like this:
|
138
|
+
Be careful when including repos inside of your test directory. If you're using a runner that looks for patterns such as `*_test.rb` to run your hatchet tests, it may run the tests inside of the repos. To prevent this problem, move your repos directory out of `test/` or into specific directories such as `test/hatchet`. Then change your pattern. If you are using `Rake::TestTask`, it might look like this:
|
146
139
|
|
147
140
|
t.pattern = 'test/hatchet/**/*_test.rb'
|
148
141
|
|
149
|
-
|
150
|
-
is in your best interest to not change them or your tests may
|
151
|
-
spontaneously fail. In the future we may create a hatchet.lockfile or
|
152
|
-
something to declare the commit
|
142
|
+
When basing tests on external repos, do not change the tests or they may spontaneously fail. We may create a hatchet.lockfile or something to declare the commit in the future.
|
153
143
|
|
154
144
|
|
155
145
|
## Deploying apps
|
@@ -164,29 +154,29 @@ HATCHET_BUILDPACK_BRANCH=master
|
|
164
154
|
|
165
155
|
If you do not specify `HATCHET_BUILDPACK_URL` the default Ruby buildpack will be used. If you do not specify a `HATCHET_BUILDPACK_BRANCH` the current branch you are on will be used. This is how the Ruby buildpack runs tests on branches on travis (by leaving `HATCHET_BUILDPACK_BRANCH` blank).
|
166
156
|
|
167
|
-
|
157
|
+
If the `ENV['HATCHET_RETRIES']` is set to a number, deploys are expected to work and automatically retry that number of times. Due to testing using a network and random failures, setting this value to `3` retries seems to work well. If an app cannot be deployed within its allotted number of retries, an error will be raised.
|
168
158
|
|
169
|
-
If you are testing an app that is supposed to fail deployment you can set the `allow_failure: true` flag when creating the app:
|
159
|
+
If you are testing an app that is supposed to fail deployment, you can set the `allow_failure: true` flag when creating the app:
|
170
160
|
|
171
161
|
```ruby
|
172
162
|
Hatchet::Runner.new("no_lockfile", allow_failure: true).deploy do |app|
|
173
163
|
```
|
174
164
|
|
175
|
-
After the block finishes your app will be queued to be removed from heroku. If you are investigating a deploy, you can add the `debug: true` flag to your app:
|
165
|
+
After the block finishes, your app will be queued to be removed from heroku. If you are investigating a deploy, you can add the `debug: true` flag to your app:
|
176
166
|
|
177
167
|
```ruby
|
178
168
|
Hatchet::Runner.new("rails3_mri_193", debug: true).deploy do |app|
|
179
169
|
```
|
180
170
|
|
181
|
-
|
171
|
+
After Hatchet is done deploying your app, it will remain on Heroku. It will also output the name of the app into your test logs so that you can `heroku run bash` into it for detailed postmortem.
|
182
172
|
|
183
|
-
If you are wanting to run a test against a specific app without deploying to it, you can
|
173
|
+
If you are wanting to run a test against a specific app without deploying to it, you can specify the app name like this:
|
184
174
|
|
185
175
|
```ruby
|
186
176
|
app = Hatchet::Runner.new("rails3_mri_193", name: "testapp")
|
187
177
|
```
|
188
178
|
|
189
|
-
Deploying the app takes a few minutes
|
179
|
+
Deploying the app takes a few minutes. You may want to skip deployment to make debugging faster.
|
190
180
|
|
191
181
|
If you need to deploy using a different buildpack you can specify one manually:
|
192
182
|
|
@@ -197,7 +187,7 @@ def test_deploy
|
|
197
187
|
# ...
|
198
188
|
```
|
199
189
|
|
200
|
-
You can specify multiple buildpacks by passing in an
|
190
|
+
You can specify multiple buildpacks by passing in an array.
|
201
191
|
|
202
192
|
You can use `Hatchet::App.default_buildpack` to get the buildpack URL and branch specified by environment variables:
|
203
193
|
|
@@ -221,7 +211,7 @@ Hatchet::Runner.new("rails3_mri_193").deploy do |app|
|
|
221
211
|
end
|
222
212
|
```
|
223
213
|
|
224
|
-
If you told Hatchet to `allow_failure: true
|
214
|
+
If you told Hatchet to `allow_failure: true`, then the full output of the failed build will be in `app.output` even though the app was not deployed. It is a good idea to test against the output for text that should be present. Using a testing framework such as `Test::Unit` a failed test output may look like this:
|
225
215
|
|
226
216
|
```ruby
|
227
217
|
Hatchet::Runner.new("no_lockfile", allow_failure: true).deploy do |app|
|
@@ -233,14 +223,14 @@ Since an error will be raised on failed deploys you don't need to check for a de
|
|
233
223
|
|
234
224
|
## Running Processes
|
235
225
|
|
236
|
-
Often times asserting output of a build can only get you so far, and you will need to actually run a task on the dyno. To run a non-interactive command such as `heroku run ls
|
226
|
+
Often times asserting output of a build can only get you so far, and you will need to actually run a task on the dyno. To run a non-interactive command such as `heroku run ls`, you can use the `app.run()` command without passing a block:
|
237
227
|
|
238
228
|
```ruby
|
239
229
|
Hatchet::Runner.new("rails3_mri_193").deploy do |app|
|
240
230
|
assert_match "applications.css", app.run("ls public/assets")
|
241
231
|
```
|
242
232
|
|
243
|
-
This is useful for checking the existence of generated files such as assets.
|
233
|
+
This is useful for checking the existence of generated files such as assets. To run an interactive session such as `heroku run bash` or `heroku run rails console`, run the command and pass a block:
|
244
234
|
|
245
235
|
```
|
246
236
|
Hatchet::Runner.new("rails3_mri_193").deploy do |app|
|
@@ -248,7 +238,7 @@ Hatchet::Runner.new("rails3_mri_193").deploy do |app|
|
|
248
238
|
end
|
249
239
|
```
|
250
240
|
|
251
|
-
This is the prefered way to run commands against the app. You can also string together commands in a session,
|
241
|
+
This is the prefered way to run commands against the app. You can also string together commands in a session, but it's less deterministic due to difficulties in driving a REPL programatically via [repl_runner](http://github.com/schneems/repl_runner).
|
252
242
|
|
253
243
|
|
254
244
|
```ruby
|
@@ -260,11 +250,11 @@ Hatchet::Runner.new("rails3_mri_193").deploy do |app|
|
|
260
250
|
end
|
261
251
|
```
|
262
252
|
|
263
|
-
Please read the docs on [repl_runner](http://github.com/schneems/repl_runner) for more info. The only interactive commands that are supported out of the box are `rails console`, `bash`, and `irb
|
253
|
+
Please read the docs on [repl_runner](http://github.com/schneems/repl_runner) for more info. The only interactive commands that are supported out of the box are `rails console`, `bash`, and `irb`. It is fairly easy to add your own though.
|
264
254
|
|
265
255
|
## Modify Application Files on Disk
|
266
256
|
|
267
|
-
While template apps provided from your `hatchet.json` can provide
|
257
|
+
While template apps provided from your `hatchet.json` can provide different test cases, you may want to test minor varriations of an app. You can do this by using the `before_deploy` hook to modify files on disk inside of an app in a threadsafe way that will only affect the app's local instance:
|
268
258
|
|
269
259
|
```ruby
|
270
260
|
Hatchet::App.new("default_ruby", before_deploy: { FileUtils.touch("foo.txt")}).deploy do
|
@@ -313,16 +303,16 @@ end
|
|
313
303
|
|
314
304
|
Call the `run_ci` method on the hatchet `Runner`. The object passed to the block is a `Hatchet::TestRun` object. You can call:
|
315
305
|
|
316
|
-
- `test_run.output`
|
317
|
-
- `test_run.app`
|
306
|
+
- `test_run.output` will have the setup and test output of your tests.
|
307
|
+
- `test_run.app` has a reference to the "app" you're testing against, however currently no `heroku create` is run (as it's not needed to run tests, only a pipeline and a blob of code).
|
318
308
|
|
319
309
|
An exception will be raised if either the test times out or a status of `:errored` or `:failed` is returned. If you expect your test to fail, you can pass in `allow_failure: true` when creating your hatchet runner. If you do that, you'll also get access to different statuses:
|
320
310
|
|
321
|
-
- `test_run.status`
|
311
|
+
- `test_run.status` will return a symbol of the status of your test. Statuses include, but are not limited to `:pending`, `:building`, `:errored`, `:creating`, `:succeeded`, and `:failed`
|
322
312
|
|
323
313
|
You can pass in a different timeout to the `run_ci` method `run_ci(timeout: 300)`.
|
324
314
|
|
325
|
-
You
|
315
|
+
You probably need an `app.json` in the root directory of the app you're deploying. For example:
|
326
316
|
|
327
317
|
```json
|
328
318
|
{
|
@@ -338,7 +328,7 @@ You will likely need an `app.json` in the root directory of the app you're deplo
|
|
338
328
|
|
339
329
|
This is on [a Rails5 test app](https://github.com/sharpstone/rails5_ruby_schema_format/blob/master/app.json) that needs the database to run.
|
340
330
|
|
341
|
-
Do **NOT** specify a `buildpacks` key in the `app.json`
|
331
|
+
Do **NOT** specify a `buildpacks` key in the `app.json` because Hatchet will automatically do this for you. If you need to set buildpacks you can pass them into the `buildpacks:` keword argument:
|
342
332
|
|
343
333
|
```
|
344
334
|
buildpacks = []
|
@@ -354,23 +344,23 @@ end
|
|
354
344
|
|
355
345
|
Once you've got your tests working locally, you'll likely want to get them running on Travis because a) CI is awesome, and b) you can use pull requests to run your all your tests in parallel without having to kill your network connection.
|
356
346
|
|
357
|
-
|
347
|
+
Set the `HATCHET_DEPLOY_STRATEGY` to `git`.
|
358
348
|
|
359
|
-
To run on travis you will need to configure your `.travis.yml` to run the appropriate commands and to set up encrypted data so you can run tests against a valid heroku user.
|
349
|
+
To run on travis, you will need to configure your `.travis.yml` to run the appropriate commands and to set up encrypted data so you can run tests against a valid heroku user.
|
360
350
|
|
361
|
-
For reference see the `.travis.yml` from [hatchet](https://github.com/heroku/hatchet/blob/master/.travis.yml) and the [heroku-ruby-buildpack](https://github.com/heroku/heroku-buildpack-ruby/blob/master/.travis.yml). To make running on travis easier there is a rake task in Hatchet that can be run before your tests are executed
|
351
|
+
For reference see the `.travis.yml` from [hatchet](https://github.com/heroku/hatchet/blob/master/.travis.yml) and the [heroku-ruby-buildpack](https://github.com/heroku/heroku-buildpack-ruby/blob/master/.travis.yml). To make running on travis easier, there is a rake task in Hatchet that can be run before your tests are executed
|
362
352
|
|
363
353
|
```yml
|
364
354
|
before_script: bundle exec hatchet ci:setup
|
365
355
|
```
|
366
356
|
|
367
|
-
I recommend signing up for a new heroku account for running your tests on travis
|
357
|
+
I recommend signing up for a new heroku account for running your tests on travis to prevent exceding your API limit. Once you have the new api token, you can use this technique to [securely send travis the data](http://docs.travis-ci.com/user/environment-variables/#Secure-Variables).
|
368
358
|
|
369
359
|
```sh
|
370
360
|
$ travis encrypt HEROKU_API_KEY=<token> --add
|
371
361
|
```
|
372
362
|
|
373
|
-
If your Travis tests are containerized, you may need sudo to complete this successfully. In that case,
|
363
|
+
If your Travis tests are containerized, you may need sudo to complete this successfully. In that case, add the following:
|
374
364
|
|
375
365
|
```yml
|
376
366
|
before_script: bundle exec hatchet ci:setup
|
data/lib/hatchet/app.rb
CHANGED
@@ -9,7 +9,7 @@ module Hatchet
|
|
9
9
|
HATCHET_BUILDPACK_BRANCH = -> { ENV['HATCHET_BUILDPACK_BRANCH'] || ENV['HEROKU_TEST_RUN_BRANCH'] || Hatchet.git_branch }
|
10
10
|
BUILDPACK_URL = "https://github.com/heroku/heroku-buildpack-ruby.git"
|
11
11
|
|
12
|
-
attr_reader :name, :stack, :directory, :repo_name
|
12
|
+
attr_reader :name, :stack, :directory, :repo_name, :app_config
|
13
13
|
|
14
14
|
class FailedDeploy < StandardError
|
15
15
|
def initialize(app, output)
|
@@ -298,8 +298,16 @@ module Hatchet
|
|
298
298
|
@pipeline_id = result["id"]
|
299
299
|
end
|
300
300
|
|
301
|
-
#
|
302
|
-
#
|
301
|
+
# when the CI run finishes, the associated ephemeral app created for the test run internally gets removed almost immediately
|
302
|
+
# the system then sees a pipeline with no apps, and deletes it, also almost immediately
|
303
|
+
# that would, with bad timing, mean our test run info poll in wait! would 403, and/or the delete_pipeline at the end
|
304
|
+
# that's why we create an app explictly (or maybe it already exists), and then associate it with with the pipeline
|
305
|
+
# the app will be auto cleaned up later
|
306
|
+
self.setup!
|
307
|
+
Hatchet::RETRIES.times.retry do
|
308
|
+
couple_pipeline(@name, @pipeline_id)
|
309
|
+
end
|
310
|
+
|
303
311
|
test_run = TestRun.new(
|
304
312
|
token: api_key,
|
305
313
|
buildpacks: @buildpacks,
|
@@ -315,6 +323,7 @@ module Hatchet
|
|
315
323
|
test_run.wait!(&block)
|
316
324
|
ensure
|
317
325
|
delete_pipeline(@pipeline_id) if @pipeline_id
|
326
|
+
@pipeline_id = nil
|
318
327
|
end
|
319
328
|
|
320
329
|
def pipeline_id
|
@@ -325,6 +334,10 @@ module Hatchet
|
|
325
334
|
api_rate_limit.call.pipeline.create(name: @name)
|
326
335
|
end
|
327
336
|
|
337
|
+
def couple_pipeline(app_name, pipeline_id)
|
338
|
+
api_rate_limit.call.pipeline_coupling.create(app: app_name, pipeline: pipeline_id, stage: "development")
|
339
|
+
end
|
340
|
+
|
328
341
|
def source_get_url
|
329
342
|
create_source
|
330
343
|
@source_get_url
|
data/lib/hatchet/test_run.rb
CHANGED
@@ -160,6 +160,9 @@ module Hatchet
|
|
160
160
|
app_json["environments"] ||= {}
|
161
161
|
app_json["environments"]["test"] ||= {}
|
162
162
|
app_json["environments"]["test"]["buildpacks"] = @buildpacks.map {|b| { url: b } }
|
163
|
+
app_json["environments"]["test"]["env"] ||= {}
|
164
|
+
app_json["environments"]["test"]["env"] = @app.app_config.merge(app_json["environments"]["test"]["env"]) # copy in explicitly set app config
|
165
|
+
app_json["stack"] ||= @app.stack if @app.stack && !@app.stack.empty?
|
163
166
|
File.open("app.json", "w") {|f| f.write(JSON.generate(app_json)) }
|
164
167
|
|
165
168
|
`tar c . | gzip -9 > slug.tgz`
|
data/lib/hatchet/version.rb
CHANGED
data/test/hatchet/ci_too_test.rb
CHANGED
@@ -3,9 +3,17 @@ require 'test_helper'
|
|
3
3
|
# Split out to be faster
|
4
4
|
class CITestToo < Minitest::Test
|
5
5
|
def test_ci_create_app_with_stack
|
6
|
-
Hatchet::GitApp.new("rails5_ruby_schema_format")
|
6
|
+
app = Hatchet::GitApp.new("rails5_ruby_schema_format")
|
7
|
+
app.run_ci do |test_run|
|
7
8
|
assert_match "Ruby buildpack tests completed successfully", test_run.output
|
8
9
|
assert_equal :succeeded, test_run.status
|
10
|
+
refute_nil app.pipeline_id
|
11
|
+
|
12
|
+
api_rate_limit = app.api_rate_limit.call
|
13
|
+
couplings = api_rate_limit.pipeline_coupling.list_by_pipeline(app.pipeline_id)
|
14
|
+
coupled_app = api_rate_limit.app.info(couplings.first["app"]["id"])
|
15
|
+
assert_equal app.name, coupled_app["name"]
|
9
16
|
end
|
17
|
+
assert_nil app.pipeline_id
|
10
18
|
end
|
11
19
|
end
|
metadata
CHANGED
@@ -1,14 +1,14 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: heroku_hatchet
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
version: 4.0
|
4
|
+
version: 4.1.0
|
5
5
|
platform: ruby
|
6
6
|
authors:
|
7
7
|
- Richard Schneeman
|
8
8
|
autorequire:
|
9
9
|
bindir: bin
|
10
10
|
cert_chain: []
|
11
|
-
date:
|
11
|
+
date: 2020-01-31 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: platform-api
|
@@ -186,6 +186,7 @@ executables:
|
|
186
186
|
extensions: []
|
187
187
|
extra_rdoc_files: []
|
188
188
|
files:
|
189
|
+
- ".github/workflows/check_changelog.yml"
|
189
190
|
- ".gitignore"
|
190
191
|
- ".travis.yml"
|
191
192
|
- CHANGELOG.md
|
@@ -250,7 +251,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
|
|
250
251
|
- !ruby/object:Gem::Version
|
251
252
|
version: '0'
|
252
253
|
requirements: []
|
253
|
-
rubygems_version: 3.
|
254
|
+
rubygems_version: 3.1.2
|
254
255
|
signing_key:
|
255
256
|
specification_version: 4
|
256
257
|
summary: Hatchet is a an integration testing library for developing Heroku buildpacks.
|