search

devpunks / snuggsi

snuggsi ツ - Easy Custom Elements in ~1kB
https://snuggsi.com
MIT License
395 stars 17 forks source link

Add test suite coverage to deployment #175

Closed snuggs closed 5 years ago

snuggs commented 5 years ago

Going off the awesome work we did in #164 we now have a fairly stable (and well tested) build pipeline.

🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 #WOOT!!!! 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉 🎉

Coverage & Lint are on deck.

Thanks for setting the bin/crank foundation @tmornini @pachonk. NOW is where the rubber meets the road.

snuggs commented 5 years ago

https://travis-ci.org/devpunks/snuggsi/builds/402507678

HMMMM. Well the great news is tests work (TOO well). @tmornini @pachonk any idea why the suite is running twice? I know the tests had been running before but perhaps shouldn't be in bin/crank? It works great for local because if any of the steps in bin/crank don't pass it disables deployment.

Thoughts... 🤔

snuggs commented 5 years ago

@brandondees @tmornini @pachonk #PING.

brandondees commented 5 years ago

¯\(ツ)/¯

brandondees commented 5 years ago

$ bin/test && bin/cover does bin/cover run the tests again?

rianby64 commented 5 years ago

Looks like it does, @brandondees

snuggs commented 5 years ago

@brandondees @rianby64 hmmm seems like bin/cover is commented tho. @brandondees where do you see this conjunction? I was gonna address after this gets merged. I have no clue why it's running twice. Perhaps @tmornini made some setting somewhere in Travis.

https://github.com/devpunks/snuggsi/pull/175/files#diff-37f78a78f215090e9287557d4f6271bfR6

rianby64 commented 5 years ago

Check this out

https://github.com/devpunks/snuggsi/blob/352f820308e0f9e9b3900f5f4c5da38590f39411/.travis.yml#L20

Right in the .travis.yml you are calling twice the test process. Just put - bin/crack and that will be enough, I think. Or, leave it as - bin/cover, because cover already fires the test process.

snuggs commented 5 years ago

@rianby64 you nailed it! I would have never thought to look in there as it was @tmornini and @pachonk who worked on the integration. It feels like there should be a bin/integrate to go with our ontology. @brandondees since i've known him has always reminded me developers should have well named "helpers" as well. Not just code.

"integrate" an "integration" sounds like what we are doing here. Implementation details can be tucked in there. Either way feels better than having a conjunction (&&) for a "single" entry point nonetheless.

I'll "WIP" something up (pun intended) 😎

snuggs commented 5 years ago

@brandondees I guess the first question to ask is are they "bin STUBS" or "SCRIPTS"?

I kinda get stubs...and scripts feels like a little more than what we are doing here (which is just #CATAT "Call A Thing A Thing")

References

Tripped over this while updating https://github.com/devpunks/snuggsi/tree/master/bin#bin-scripts

capture d ecran 2018-07-14 a 10 21 12

brandondees commented 5 years ago

@snuggs sometimes you can't get away from what people are already calling a thing. sometimes you can (but beware the confusion you'll cause).

binstubs are just scripts that can be executed directly: bin/deploy as opposed to sh bin/deploy

tmornini commented 5 years ago

Not a fan of putting all runables in bin/

Put all things in context, or it's Fake News, right?

If bin/test tests the entire system, it's context is /, therefore it really belongs in /test

Which is to say bin/text should test everything in bin/. 😄

brandondees commented 5 years ago

I don't disagree with the ideology, @tmornini, but running things from in bin/* is pretty widely established convention, mirroring unix, and there's some pragmatic benefits to rolling with that for the sake of convenience and adoption. We're in the process of standardizing a set of common command names that should be expected to work in any dev project regardless of the tech specifics (language, framework, architecture, etc)

tmornini commented 5 years ago

@brandondees Any project that needs to work with snuggsi is going to need to execute the right commands.

It's irrelevant where those commands live.

You're welcome to put the commands into the wrong context if you like, of course -- just like you've welcome to write hard-to-read, buggy, inefficient code. After all, that's how most code is written so perhaps this project should follow those conventions as well. 😄

snuggs commented 5 years ago

@tmornini @brandondees perhaps can have cake and eat it too? We do use this in package.json for this very reason so it's best to get this correct as then can just be an implementation detail.

https://docs.npmjs.com/files/package.json#bin

snuggs commented 5 years ago

@tmornini done and done! Bash scripting you'd be proud of. :-)

/cc @rianby64 @brandondees

brandondees commented 5 years ago

@snuggs see, that wasn't so hard was it?