Ensure Aruba can be updated

[gonzalo-bulnes]

When I maintain a Dredd Hooks package
I want the standard test suite that documents it to rely on up-to-date tools
So that I can find help and documentation easily if needed

See https://dredd.readthedocs.io/en/latest/hooks/
See also apiaryio/dredd-hooks-ruby#26

Fixes #8

[honzajavorek]

Thanks! I like the changes, we just need the Travis build get passing.

[gonzalo-bulnes]

Hi @honzajavorek,

Seeing that the builds of this project have always been historically red and because there is actually no implementation of Dredd Hooks to run the features against in this repo, I ignored the failing build. (And indeed thought that if I was right, then the Travis CI web hook could probably be disabled?)

Am I missing something?

[honzajavorek]

Hmm, that's a good point. I didn't have the luck to contribute to this repo yet, so I didn't realize what the state of the Travis integration is here. I think we're good to go then.

…

On Tue, 17 Jan 2017 at 23:35, Gonzalo Bulnes Guilpain < ***@***.***> wrote: Hi @honzajavorek <https://github.com/honzajavorek>, Seeing that the builds of this project have always been historically red <https://travis-ci.org/apiaryio/dredd-hooks-template/builds> and because there is actually no implementation of Dredd Hooks to run the features against in this repo, I ignored the failing build. (And indeed thought that if I was right, then the Travis CI web hook could probably be disabled?) Am I missing something? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#9 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARTMcxHoapPZBMTNPJtP4sZk98I29rJks5rTUIrgaJpZM4Ljypw> .

[honzajavorek]

@gonzalo-bulnes Thank you very much! You are great help in this! 🎉 🙇 👍

[gonzalo-bulnes]

@honzajavorek Thinking about testing this template features, it is probably possible to perform a basic syntax check in the test suite (I'll take a closer look at this Gherkin linter to see if it provides syntax validation - I'm skipping the Java-based option for that I think it would be much heavier to put in place). Automated sntax validation is probably a good think to have in a templates project.

Then, eventually, maybe one of the implementations could be used to test-proof the templates? Whether this is a good idea or not remains to be seen, but I'm thinking that the Golang implementation for example, given Golang's ability to produce static binaries (ignore the Docker-side of the story), could be a case of drop-the-binary-in-place to get an actual run of the template features again a reference implementation.

What do you think?

[honzajavorek]

I actually thought I would just turn the Travis CI off on this repo (while keeping the configuration in .travis.yml), but the linter sounds good to me (if the current contents of the repo pass it 😜 ).

Regarding having an implementation here to test - I'm not sure about that. The test suite is a source of truth and all hooks should implement it. What would be the intention behind having a build like that? We consider Ruby and Python hooks to be reference implementations (since they were first, made by us, and they're under apiaryio/ organisation, so we can easily fix quickly anything on them if needed), so if any implementation would be present here, it would be one of those two. But I'm still not sure what would be the intention of the build. Would it be testing the implementation against the test suite template? That's already done in each repo. Or maybe vice versa? Testing whether changes in the template won't break builds for the implementations? For this use case, I like the approach we took much more - driving the change from one of the reference repos, ensuring the change is valid and tests pass, and porting it to the rest of the test suite instances.

Some kind of watchdog if all hook repos have the same test suite as is in this repo would make more sense to me. But that's not something to be done in CI build, since it's changes-in-other-repos-related, not changes-in-this-repo-related.

[gonzalo-bulnes]

Hi @honzajavorek,

The syntax validation is definitely easy to put in place. I opened a PR (#10).

Testing whether changes in the template won't break builds for the implementations? For this use case, I like the approach we took much more - driving the change from one of the reference repos, ensuring the change is valid and tests pass, and porting it to the rest of the test suite instances.

Yes, the idea was making sure breaking changes are explicit. That being said, given the current approach is working well, I cannot agree more. My comment was really just about listing possibilities and evaluating the complexity involved in each case.

By the way, I think that #8 (and #2?) can be closed now : )

[honzajavorek]

@gonzalo-bulnes

I cannot agree more. My comment was really just about listing possibilities and evaluating the complexity involved in each case.

Good!

I opened a PR (#10).

Did I already tell you that you're awesome? 😄

By the way, I think that #8 (and #2?) can be closed now : )

Yes, sure! Going to close them right away 🔨

[ApiaryBot]

🎉 This PR is included in version 1.0.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀