Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a dummy key in ./package.json or other .json for commit hash for deployment access #426

Closed
Martii opened this issue Nov 18, 2014 · 2 comments · Fixed by #636
Closed
Labels
CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. enhancement Something we do have implemented already but needs improvement upon to the best of knowledge.
Milestone

Comments

@Martii
Copy link
Member

Martii commented Nov 18, 2014

This would need to be extremely unique so that npm, node and whatever host provider has no chance of using it if in the ./package.json. Deploy routine would need to replace it on the fly... GM currently uses sed to replace their <em:version> on the build fly and has been working successfully for many, many, many years now.

Applies to #249 and mentioned in #296 and briefly retouched on in #425 dependency ... since our current host provider doesn't validate properly the "version" we can't use it in the extended semver syntax like every other package system does... e.g. time to create a new key/system that should be ignored by any host provider.

I'm open to naming suggestions or perhaps an alternate method.

@Martii Martii added enhancement Something we do have implemented already but needs improvement upon to the best of knowledge. needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. labels Nov 18, 2014
@Martii Martii self-assigned this Nov 18, 2014
@Martii Martii added this to the #249 milestone Nov 18, 2014
@Martii Martii assigned Martii and unassigned Martii Nov 22, 2014
Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue Dec 4, 2014
* This may need to be reverted if nodejitsu/*jitsu* chokes next deploy but is needed for testing

See also:
* http://semver.org/ Item 10

This is the preferred methodology for OpenUserJS#426 however a lot depends on the hosting site.
@Martii
Copy link
Member Author

Martii commented Dec 5, 2014

Current nodejitsu/jitsu appears to strip build metadata completely out but appears to deploy okay... leaving placeholder in for determining if they ever change their backend.

See also:

Current clipped package.json:

...
version": "0.1.6-3",
...

Current process.version === 0.1.6-3


Issue dependency at #425

Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue May 29, 2015
* Continue to use parallel *async* to retrieve info via git abstract
* New dep of *git-rev* to abstract a little direct `exec` is also available
* Bump *node* engine to latest 0.12.4

Closes OpenUserJS#426 and post dependency of OpenUserJS#635 after merge.
Martii pushed a commit to Martii/OpenUserJS.org that referenced this issue May 29, 2015
* Remove *jitsu* reference as soon to be obsolete with OpenUserJS#635

Applies to OpenUserJS#636 and OpenUserJS#426
@sizzlemctwizzle
Copy link
Member

Really great work on this! I love that you can see exactly what code is running in production.

@Martii Martii removed their assignment May 30, 2015
@Martii Martii removed the needs discussion Blah, blah, blah, wahh, wahh, wahh, etc. label Aug 1, 2015
@OpenUserJS OpenUserJS locked as resolved and limited conversation to collaborators Apr 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
CODE Some other Code related issue and it should clearly describe what it is affecting in a comment. enhancement Something we do have implemented already but needs improvement upon to the best of knowledge.
Development

Successfully merging a pull request may close this issue.

2 participants