Switch node host providers

Through all of the deployment woes that we've been having for well over a week it's probably about time to hear some alternatives for hosting OUJS somewhere more reliable.

Basically the recent issue is with npm and file permissions with remote npm not being configured properly on their end.

As I have constantly stated certain items would be best served within our realm of control... unfortunately since nodejitsu/jitsu appears to not honor the r switch and is very buggy just in general when deployed from multiple locations it is about time to consider the alternatives.

Any ideas or suggestions?

What deployment issues?

We weren't able to deploy until today... after 8ish days of talking back and forth with nodejitsu. Sizzle temporarily handed over deployment to me yesterday ... which has been relinquished... and I discovered that jitsu is flawed (the deployment app nodejitsu uses on their dummy front-end)... and the backend scripts which accept the tokens and basic commands and then calls whatever scripts that are closed source on their end.

Basically my last correspondence with nodejitsu was that the r switch isn't supported and we shouldn't even think about trying to use it... even though it's in the options. One of my issues mentioned using the gh hash which can easily be achieved with the follow deploy script:

#!/bin/bash
HEAD=`git rev-parse --short HEAD`
VER=`node -pe 'JSON.parse(process.argv[1]).version' "$(cat package.json)"`

jitsu deploy -c -r $VER-hash-$HEAD

unfortunately this causes nodejitsu to bomb miserably.... even with a custom numerical commit instead of a sha1 sum clipped hash it now fails. (numerical was working about 5 hours ago until they downgraded npm for the initial reason why we couldn't deploy).

Basically nodejitsu in my humble opinion is unreliable at this time... too many problems that are completely out of our control. Perhaps a virtual Linux host would be better suited for this.

@sizzlemctwizzle

You may also notice that our current version on production is foo'd since this is a different location than sizzle... see https://openuserjs.org/about#welcome with the lack of -104... jitsu is definitely bad about this across systems... @sizzlemctwizzle has been made aware of all of this too... which is why we should have the gh commit hash... also our snapshots are foo'd in the history on nodejitsu and their service says that we have multiple snapshots active. (we already have a snapshot of 0.1.3 when that was bumped and now we are back to it... so duplication).

What does the r switch do? Why do we need to use it?

Sets the ./package.json version for deployment. npm will fail if it is not semver x.x.x but that is why the -whatever exists. You can see how it is being successfully used on npmjs.org with https://www.npmjs.org/package/select2 ... anyhow... because I deployed... the value that it increments is pretty much random... sizzles "jitsu deploy version head" is at "-103" right now ... so his next should be "-104"... but that's not always the case when deployment happens across multiple systems... at one point the "auto deploy version" skipped to "-10" and then silently did "-104" and then did it again at "-104" then we are at "-106"... basically this is the auto-numbering flaw... but the fact is if we had the GH commit hash this wouldn't mess up our snapshots... e.g. we could go back to a specific version ... but because we have ~~two~~ three of "0.1.3" now... it is impossible to revert since all are considered active in their backend.

Anyhow... basically nodejitsu isn't reliable at this point in time and imo historically since I've been active with this project. I've done my best to work with their support on this and their last reply was to use their auto-naming system instead of a feature they claim to support... it's been a total headache for sizzle and a minor one for me trying to debug their application... but since jitsu is just a dummy front for their backend scripts most of the issues were remote... and now they've killed/broken the r switch altogether in their backend.

If anyone is still wondering if you change https://github.com/OpenUserJs/OpenUserJS.org/blob/master/package.json#L4 to be "0.1.3-hash-9c43c59" (that's our current head and normalized so it could be hyperlinked to https://github.com/OpenUserJs/OpenUserJS.org/tree/9c43c59) and run dev... npm and node currently have zero issues with this... also the "-browserify-fix" on select2 has no issues with the npmjs registry... so nodejitsu/jitsu still has a validation issue in their backend.

Arrgh!

...
info:    Creating snapshot 0.1.4-4
info:    Uploading: [=============================] 100%
error:   Error running command deploy
error:   Error building snapshot
error:   Nodejitsu Error (500): Internal Server Error
...
info:    Nodejitsu not ok

... this isn't helpful. :(

Snapshot was built... uploaded okay... then it claims the snapshot couldn't be built...WHAT!?!?! ... this is a paradox in nomenclature and very non-descriptive.

Navigation Menu

Repository navigation

Switch node host providers #425

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Switch node host providers #425

Description

Activity

Zren commented on Nov 18, 2014

Martii commented on Nov 18, 2014

Martii commented on Nov 18, 2014

Zren commented on Nov 18, 2014

Martii commented on Nov 18, 2014

Martii commented on Nov 18, 2014

Martii commented on Nov 25, 2014

Martii commented on Feb 11, 2015

Martii commented on May 30, 2015

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions