basic travis-ci setup (#97)

[tmornini]

Just requested access to devpunks organization so I can add devpunks/snuggsi to travis-ci so I can test this. :-)

[tmornini]

Ok, I received some authorization, but travis-ci now says:

Sorry, but we can't find any repositories you have admin access to.

😃

[snuggs]

@tmornini check email. You got the 🔑 🔑 🔑 s

[tmornini]

@snuggs Now getting "You require admin rights to enable these repositories"

[snuggs]

@tmornini confused ... :thinking:

[tmornini]

Well damn! Perhaps I need to reauth.

[tmornini]

@snuggs OK, I just needed to re-auth.

I have it this far now:

npm ERR! need auth You need to authorize this machine using `npm adduser`

[tmornini]

@snuggs Also, can you help me understand these 3 lines?

https://github.com/devpunks/snuggsi/blob/3f9072e772999d5e04883a6d0cc5bbf54617e133/.travis.yml#L4-L6

Travis builds nodejs 7 and iojs separately and independently.

What does that mean? 😄

Clarification: I copy/pasta'd those from travis-ci documentation. :-)

[brandondees]

i don't think there's any real need to include iojs, which was the nodejs fork before they re-merged, if i understand/recall correctly.

[tmornini]

@brandondees Thanks, removed!

[tmornini]

@snuggs @pachonk @brandondees I would appreciate help in debugging the build, as I have zero idea what's signal and what's noise.

[brandondees]

Parse error at ./dist/snuggsi.es:1,0
const HTMLLinkElement = function
^
ERROR: Unexpected token: keyword (const)
    at JS_Parse_Error.get (eval at <anonymous> (/home/travis/build/devpunks/snuggsi/node_modules/uglify-js/tools/node.js:21:1), <anonymous>:79:23)
    at fatal (/home/travis/build/devpunks/snuggsi/node_modules/uglify-js/bin/uglifyjs:268:52)
    at run (/home/travis/build/devpunks/snuggsi/node_modules/uglify-js/bin/uglifyjs:225:9)
    at Object.<anonymous> (/home/travis/build/devpunks/snuggsi/node_modules/uglify-js/bin/uglifyjs:155:5)
    at Module._compile (module.js:571:32)
    at Object.Module._extensions..js (module.js:580:10)
    at Module.load (module.js:488:32)
    at tryModuleLoad (module.js:447:12)
    at Function.Module._load (module.js:439:3)
    at Module.runMain (module.js:605:10)
bin/compress: line 2: bro: command not found
bin/compress: line 5: bro: command not found
block split points: (hex:)

not sure about all this but it definitely appears that brotli isn't installed, which probably requires a bit of hand configuration to get running.

[brandondees]

error: src refspec master does not match any.
error: failed to push some refs to 'https://github.com/devpunks/snuggsi.git'
v0.7.30
error: src refspec master does not match any.
error: failed to push some refs to 'https://github.com/devpunks/snuggsi.git'
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/devpunks/snuggsi.git/'
npm ERR! Linux 4.8.12-040812-generic
npm ERR! argv "/home/travis/.nvm/versions/node/v7.10.0/bin/node" "/home/travis/.nvm/versions/node/v7.10.0/bin/npm" "publish"
npm ERR! node v7.10.0
npm ERR! npm  v4.2.0
npm ERR! code ENEEDAUTH
npm ERR! need auth auth required for publishing
npm ERR! need auth You need to authorize this machine using `npm adduser`
npm ERR! Please include the following file with any support request:
npm ERR!     /home/travis/.npm/_logs/2017-07-11T04_51_29_311Z-debug.log
The command "bin/crank" exited with 1.

this seems like travis isn't configured with full access to the github repo, which i'm not familiar with but it should be straightforward and well documented somewhere

[tmornini]

@brandondees

failed to push some refs to 'https://github.com/devpunks/snuggsi.git' v0.7.30

Failed to push?

WTF?

[brandondees]

pull access for public projects is free, but you have to have SSH key configured or login credential authentication for SSL connections to have write access, which i believe means copying a deploy key from travis into the github repo / org / account's settings somewhere... i'd have to look up the docs for it

[brandondees]

or if you mean pushing to the repo from CI is unexpected, yeah i don't know, would have to read some code or ask the author about what that's about.

[brandondees]

I believe crank is intended to generate a new build rev for distribution, which then gets distributed both through the public site and into the github repo

[snuggs]

I believe crank is intended to generate a new build rev for distribution, which then gets distributed both through the public site and into the github repo

You know you opened pandora's box @brandondees....

Yup that was my duct tape skateboard of a "full deploy" The distributions all respectively change individually and doing a rebase etc. dance just to have "commit injection" was extremely problematic early and stepped away from preferring it. If there is a change to core then only certain files change. Afterwards bin/distribute pushes to github. That could be separated now that CI is a concern. As i referenced here https://github.com/devpunks/snuggsi/issues/103#issuecomment-314361794 all of this is only coming up because we were :eye: balling things and now have a digital scale, just figuring out where the batteries go.

@tmornini mentioned deploying after going to CI. That makes sense now but wondering how the process is when you just want to go to CI and handle the version bumps / deploy manually (only until next month). Still talking with WHATWG and going over process that aligns to a T with their release schedule. This typically tends to be 2 patch releases and a "nightly build" release daily at 8AM, 5PM and midnight. Basically aligning with how the browsers (are supposed to) increment on a daily basis. We're marching at the speed of browser implementation to the spec without having the features of a full on browser. Our test library/full platform spec implementation JSDOM (attempts to do) similar on the days they need to align updates Perhaps that's on some queue / notification system but that is a process still determining patterns that we need a touch more feedback from a few people like Domenic before setting build / distribution in stone. So i guess publish (which just makes static assets public) and distribute (which just pushes to heroku) should be revisted to see where CI sits in all that. I'm fine with pushing to github and having some process release 3 times a day but would have to be 2 patches and a version bump. Ember does a similar approach with the specs as they have a time machine that launches whether or not new code is there. If you don't make it it goes in next release. This approach prevents stagnancy.

Do realize the implementation marching forward is more important than the site. The site deployment can be a side effect to the version patch/bumps. (think bin/deploy) 2017.7.11 2017.7.11-patch-0 2017.7.11-patch-1 2017.7.12 (rinse and repeat). Which to be clear we aren't doing now and only version that makes sense is the x.7.x minor version. At least until i figure out how to name npm version patch and January 1 comes (in that order). Not SemVer but then again neither is the process that we follow to a T. Software versioning was actually crippling spec proposal implementation and was one of the major factors in the shit show of the 90s/2000s . (Extensive email threads on the matter). Time based release is a band aid on a bullet wound to the TC39 Level Process, and WHATWG DOM/HTML approach while at the same time kissing W3C's ass...because... Microsoft. Too much to cover here. And also too much to try to think about now. @brandondees has been around long enough to be familiar with how much of a shit show v0 vs v1 custom elements proposal vs implementation went the past 2 years. Wasn't good. And now are in a situation where we may have to pick up the baton and cross the finish line with the spec draft. Domenic has already started pointing in directions that need some lovin' for this all to work. We have another 5 months to go from 0 to 2018.1.1 (what @brandondees would call v1) And are aligning nicely with this July so in good shape for 2018. Key is starting on the right foot knowing July is important in regards to releases.

☝️ And that's why SEMVER means nothing without dates related to it. Avg software dev wouldn't understand but this is more about a spec process than a software process. (which snuggsi is merely conventions around specs not really a software version persay. That said must have empathy for users who can just lock in to a "monthly" year.x.x or year.month.x for a more granular "stable" version. https://unpkg.com/snuggsi should have nightlies which is handled for us by unpkg.com already. https://snuggsi.es would handle "stable" releae which is sorta a joke in regards to current platform spec implementations AKA browsers)

Hope this sheds some light of the mental gymastics behind a bunch of the setups. But I have strong opinions loosely held (as long as they respect spec timings). 😎 Please advise, any help would be appreciated as I knew this day was fast approaching.

@tmornini you can chalk up any confusion with bin scripts to (As i told you a while ago) my insecurity/lack of knowledge with this space in the first place. But these snuggsies wasn't gonna build themselves ;-)

[snuggs]

Fixes #97 #autoclose /cc @pachonk @mrbernnz

[snuggs]

This is the 💩 that we cannot avoid and would love to not have to think about it. Any way we can automate around would be great. Releasing early and often (at minimum once a day no more than a few) is a nice space that many have proposed from learning from lessons from the past. That said that's 1-3 times we could fuck up on a manual process. (which i've done already a few times since April). In our case we want to be smart and align our lib with the spec not the browser. That's proven futile in the past. And this CI process can take care of much of the "logic" over the long run.

These poll-LIE-Ticks are something we can't avoid at this level (learned the hard way) and SEMVER would basically stake our allegiance to W3C which WE DON'T want to do. They are already in quicksand with HTML5.3 snuggsi lib is "Living" Should be understandable how something so political is important to the CI process. HOW it fits in and WHAT/WHERE can be automated is a mystery wrapped in an enigma ❓ ❔ Whatever we do we are gonna have to teach devs the importance of "feature checking" instead of "version dependency" in relation to web related libraries. And there will be kicking and screaming. But I digress.

Again this cadence is merely a well thought out hypothesis. We've been told to implement and if adoption, recommendation to other implementers. Doesn't change what CI "does". Just can't #CATAT using SEMVER. @brandondees is familiar w/ proposal process.

[grepsedawk]

Let me take a look. I'm fairly decent at bash style automation. :)

On Tue, Jul 11, 2017, 4:28 AM snuggs notifications@github.com wrote:

This is the 💩 that we cannot avoid and would love to not have to think about it. Any way we can automate around would be great. Releasing early and often (at minimum once a day no more than a few) is a nice space that many have proposed from learning from lessons from the past. That said that's 1-3 times we could fuck up on a manual process. (which i've done already a few times since April).

[image: capture d ecran 2017-07-11 a 05 26 01] https://user-images.githubusercontent.com/38223/28061799-c28a359e-65f9-11e7-8549-cc5ab1b850b1.png

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/devpunks/snuggsi/pull/101#issuecomment-314387653, or mute the thread https://github.com/notifications/unsubscribe-auth/AGaPSy1sDJ8zN2SSdvX_T_kRlyjQi0Jbks5sM0A-gaJpZM4OTP-0 .

[snuggs]

@pachonk good! So what i wrote made sense? Whew... it's a backstory but at least you have clarity of where my mind has been the past few months.

[grepsedawk]

@snuggs I'm sorry, I meant a look at TravisCI pushing to GitHub for you...

[grepsedawk]

Need to pair with someone with admin access and I'll show you how to set up a REPO BASED ssh write key

[grepsedawk]

https://docs.travis-ci.com/user/deployment/

deploy:
  provider: releases
  api_key: "GITHUB OAUTH TOKEN"
  file: "FILE TO UPLOAD"
  skip_cleanup: true
  on:
    branch: nightlies
    tags: true
    node_js: 7

[grepsedawk]

Here's what I'm finding: If we want to tag from travis on certain branches and automatically upload dist, then it's super easy. If we want to do the commit strategy, we need to decide AT WHICH POINT the dist folder gets updated.

[grepsedawk]

There's also this: https://docs.travis-ci.com/user/deployment/npm/

[grepsedawk]

and this: https://docs.travis-ci.com/user/deployment/heroku/ So it stands that the only thing left to figure out is committing to the dist folder (or pointing them to the "current release" tag link)

[grepsedawk]

@tmornini When do we want to commit in the github flow, right now it wants to commit EVERY TIME there's a PR commit which wouldn't be good. Do we want to make those commits every time a commit hits master branch only?

[snuggs]

Well... We can leave deploy out @pachonk. Just as long as CI passes we have a single test run in bin/test and the bin/validate-weight are pretty much only "checks" besides installation. Baby steps on this one. Tons of shit on deck to change throughout the rest of the year as HOW things are pieced together is up for debate but definitely full steam ahead. (i.e. http/2)

[snuggs]

@brandondees just got this. Dunno if this is right. I got something similar the other day when Tom setup. This one seems for Prvt tho.

Please advise:

[grepsedawk]

@snuggs We should be able to keep it on travis-ci.org which is free.

[tmornini]

@pachonk Nice, thanks!

I think a release every time master changes makes sense. The release can point to the SHA on master.

I think we should point them to a "current release" tag link.

[tmornini]

@pachonk Would love some help finishing this up.

[grepsedawk]

@tmornini Let's just run 1 run of @snuggs 's test bash to get travis working

[tmornini]

@pachonk I don't know what that means. :-)

[grepsedawk]

Hmm, I can't find it but I believe @snuggs had a script he ran to test everything and then he calls watch bin/something

[grepsedawk]

I actually thought you were the one that made it.

[tmornini]

@pachonk I did bin/bundle (an old version that was far more flexible), but not much else.

I know FA about javascript but support @snuggs with automation where I can as he's not lazy enough. 😄

[snuggs]

I'm working on it @tmornini. also... bin/test && bin/cover is your friend @pachonk ;-)

Thanks for the "Shebang" info. just when i thought bin/bash (or whatever) vs usr/bin/env bash was. STILL don't know the diff as usr/bin is "portable"?? i'm great if you leave me in ~ but the minute i'm in / i'm LOST! THAT is my handicap (for now....) getting better by the day. Intentionally avoided / in my programming career because I was used to C:\\ pipe to grep" STILL fascinates me with unicorns. So please bear with me.

[grepsedawk]

@snuggs Looks like that's "passing" to at least get this feature closer to being merged.

[snuggs]

@brandondees we've discussed this frequently as the benefit of having "Living" versioning rather than "SEMVER" regarding moving specs. Here's a nice reference i found from Jeff Atwood on when Google started doing this a few years ago. Deeper into post deeper into binary code swapping (which I didn't know even existed). /cc @pachonk @tmornini

1. year.month.day-patch0
2. year.month.day-patch1
3. year.month.day(nightly)

RinseAndRepeat Perhaps nightly is what updates <script src=https://snuggsi.es></script> AKA main CDN...(Or Not). patch for <script src=https://unpkg.com/snuggsi></script> users. They get "edge" but no CDN. (Dev mode?). <script version=2017.1.1 src=https://snuggsi.es></script> "lock" in. (this is https://unpkg.com approach) Have already gotten some interest that after sitting on concept for a while realized takes care of all of their concerns/needs. And starts forcing towards "Well... I just 'use' it. If I want a specific i can just find a year, month, day in history to lock in to that I feel comfortable with. I'm good with that"

TL;DR;

https://blog.codinghorror.com/the-infinite-version

[tmornini]

@snuggs @pachonk @brandondees Can we have a simple split in CI behavior between:

1) master (full deploy, updates site) 2) any other branch (mini deploy, doesn't update site)

The simpler the better...

[grepsedawk]

I'm thinking let's get Travis at least TESTING and we can make a new PR after it's testing and that works.

[mrbernnz]

@tmornini @snuggs @pachonk Can I jump in on this?

[grepsedawk]

Go for it

[tmornini]

@mrbernnz Absolutely!

[tmornini]

Everyone, @snuggs and I agreed yesterday after a long call that the mid-term goal is to shoot for automatic deployment for every merge to master.

[mrbernnz]

@tmornini, @snuggs What would be the criteria to hit for automatic deploy? Is it just tests passing?

[brandondees]

test suite passing is minimum, which puts a lot of responsibility into good testing, but you can always add in more kinds of tests / criteria, such as code style linting, test coverage reporting, performance benchmarks, complexity metrics, and whatever else seems useful to check. @pachonk and I are currently working on enabling some stricter github workflow controls and more automation around test suite + security checks + style linting + coverage for a few of our projects, with the goal of building up high confidence in our team's ability to submit PRs that satisfy the criteria, and confidence that passing status checks mean that it's safe to ship.

[mrbernnz]

@brandondees Thanks for the breakdown.