shipshapecode / ember-cli-release Goto Github PK
View Code? Open in Web Editor NEWEmber CLI addon for versioned release management
License: MIT License
Ember CLI addon for versioned release management
License: MIT License
I am getting an error when I try to install the latest beta
npm ERR! enoent ENOENT: no such file or directory, chmod './my-repo/node_modules/ember-cli-release/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js'
🚨 You need to enable Continuous Integration on all branches of this repository. 🚨
To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.
Since we didn’t receive a CI status on the greenkeeper/initial
branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.
If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/
.
Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial
branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.
I just tried the latest ember-cli-release addon and ran ember release
in my working dir.
[?] Your working tree contains modifications that will be added to the release commit, proceed?: Yes
After hitting yes, not only are the modified files added to the commit, but also all untracked files. Very surprising.
I see that you call git add -a
and git commit
in case the working tree is dirty.
I think you should just use git commit --all
which does exactly the right thing, IMO - ie. it adds all changed files to the commit.
I think this issue can safely be closed as "not ember-cli-release's problem" if you are inclined, but I wanted to point it out since it bit me and might bite others.
We are using np
to create new release tags for an ember addon, and I noticed that np was complaining that the version of npm was incorrect:
[email protected] has known issues publishing when running Node.js 6. Please upgrade npm or downgrade Node and publish again. https://github.com/npm/npm/issues/5082
That was confusing because I have a newer version of npm (4.1.2) installed, but I eventually realized that because ember-cli-release has a dependency on npm "~3.5.2"
, that's why np
finds [email protected]
. I've fixed that problem locally, but I thought it is worth pointing out both that this dependency causes a conflict with np
and also that this version range for npm is known to have some publishing bugs (see this very long thread: npm/npm#5082 — in short the buggy npm versions are 3.0.0 to 3.10.0, np
checks for that range in its code).
Upgrading the npm dependency would avoid those publishing bugs (which seems like a good thing), and also avoid the conflict with np
(which probably matters less — since ember-cli-release does the same thing as np
it was my mistake to have them both in my package.json at the same time).
I tried the following config:
/* jshint node:true */
var RSVP = require('rsvp');
var publisher = require('publish');
// Create promise friendly versions of the methods we want to use
var start = RSVP.denodeify(publisher.start);
var publish = RSVP.denodeify(publisher.publish);
module.exports = {
manifest: ['package.json'],
// Publish the new release to NPM after a successful push
// If run from travis, this will look for the NPM_USERNAME, NPM_PASSWORD and
// NPM_EMAIL environment variables to publish the package as
afterPush: function() {
return start().then(function() {
return publish({});
});
}
};
...with publish added as an npm devDependency for the project.
Unfortunately, it does not seem to get triggered, and I've had to publish manually.
Most of the time I run release command with --prerelease
. It would be nice if I could set prerelease: true
in release.js
, so that the command uses --prerelease
by default, unless I specify --major
, --minor
or --patch
.
We're working on a cordova app that has has android and ios files with version numbers in addition to package.json and bower.json. Would you be open to a PR that allows apps to configure a hook that will be run by ember-cli-release when a new version number is being applied to manifest files?
😢
Hi there, would you someone familiar with the project would be open to giving an "Introduction to ember-cli-release" lightning talk at an upcoming Global Ember Meetup in the beginning of next year? We'll edit the video and give you video that you can embed into the addon's README. You can see an example of other introduction videos here https://vimeo.com/album/3607049
The talk usually covers:
What do you think?
ember-cli 2.x has been around for years and 3.0.0 is in beta
right now, yet this project is still on 1.x Several other dependencies (see list below) are multiple major versions behind the latest. This is particularly problematic for things like npm
(see #63). For this addon to continue to be useful / relevant I believe we really need to get it up to date. Is this project still maintained? Would you accept a PR updating dependencies provided that tests are still passing?
$ ncu
Using /..../ember-cli-release/package.json
[..................] \ :
chalk ^1.0.0 → ^2.3.0
git-tools ^0.1.4 → ^0.3.0
make-array ^0.1.2 → ^1.0.3
moment-timezone ^0.3.0 → ^0.5.14
nopt ^3.0.3 → ^4.0.1
npm ~3.5.2 → ~5.6.0
rsvp ^3.0.17 → ^4.8.1
semver ^4.3.1 → ^5.5.0
chai ^2.1.1 → ^4.1.2
ember-cli 1.13.13 → 2.18.1
ember-cli-dependency-checker 1.1.0 → 2.1.0
fs-extra ^0.18.0 → ^5.0.0
glob ^5.0.1 → ^7.1.2
mocha ^2.2.1 → ^5.0.0
The following dependencies are satisfied by their declared version range, but the installed versions are behind. You can install the latest versions without modifying your package file by using npm update. If you want to update the dependencies in your package file anyway, run ncu -a.
require-dir ^0.3.0 → ^0.3.2
silent-error ^1.0.0 → ^1.1.0
rimraf ^2.3.2 → ^2.6.2
We have pre-push hook, which run tests before push. With regular push all works fine, but with ember release
I got errors like
Latest version: v5.41.8
Successfully committed changes 'Released v5.41.9' locally.
[?] About to create tag 'v5.41.9' and push to remote 'origin', proceed?: Yes
Successfully created git tag 'v5.41.9' locally.
error: failed to push some refs to '[email protected]:collectrium/apollo.git'
Error: error: failed to push some refs to '[email protected]:collectrium/apollo.git'
at ChildProcess.<anonymous> (/Users/vvs/repo/apollo/node_modules/ember-cli-release/node_modules/git-tools/node_modules/spawnback/index.js:31:12)
at emitTwo (events.js:87:13)
at ChildProcess.emit (events.js:172:7)
at maybeClose (internal/child_process.js:817:16)
at Socket.<anonymous> (internal/child_process.js:319:11)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at Pipe._onclose (net.js:469:12)
After that I should push all manually. Can we add option to pass params into git push
? ( I mean --no-verify
on pushing tag )?
When I run an ember release
command with arguments, I see this:
$ ember release --premajor alpha
Successfully committed changes 'Released v0.1.0' locally.
? About to create tag 'v0.1.0' and push to remote 'origin', proceed?
I notice a mistake and cancel. But commit has already been made!
Why? ember-cli-release
is pretty unintiutive, so mistakes are common. I want to be able to confirm/cancel before it makes any actual changes.
Right now ember release
seems to create the following undesirable situation:
You'll note that github adds them as releases but doesn't show the message or show that they are the latest release
What I want is for the command to generate an actual release ala:
Am I missing some config option that will do this?
Is there a way to skip CircleCI build with the [ci skip]
tag from CircleCI?
That could be an option we pass to ember release
?
Since this addon seems to be unmaintained, and dependencies are woefully out of date, I made a forked, modernized version of this, ember-cli-release-tag.
Since there have been no responses to any issues and PRs for months (or years), and we do use that functionality somewhat often, I decided to make a mostly drop-in replacement with a more modern codebase and dependencies.
For now, this new addon is a bit streamlined and I have removed some options:
date
strategy does not accept any additional arguments anymore - it is always v19.01.16
. Feel free to provide your own custom strategy if needed.premajor
and preminor
have been dropped. Instead, always use prerelease
, which you can combine with major
(--> pre-major) or minor
(--> pre-minor), e.g. ember release --major --prerelease='beta'
For most common use cases, it should be enough to do
yarn remove ember-cli-release
yarn add ember-cli-release-tag
And continue as before.
ember release --prerelease beta
This should publish to npm with a beta
tag
npm publish --tag beta
So I just tried using ember release --minor
and everything worked as expected for my first try. It set the package.json to version 0.1.0. I just tried doing another minor release using the same ember release --minor
and I'm getting the error:
troy@troy-XPS-8300:~/development/bk-core-services$ ember release --minor
Skipped tagging, HEAD already at tag: v0.1.0
Shouldn't it bump it to v0.1.1? What am I doing wrong?
Would it be possible to include the config/release.js in the manifest files so that the version can be read in the App? (I would like to be able to display it in the navbar).
On the latest ember-cli, the following deprecation warning occurs:
DEPRECATION: Overriding init without calling this._super is deprecated. Please call `this._super.init && this._super.init.apply(this, arguments);` addon: `release`
Not that big of a deal, but it would be nice to avoid changing the whitespace, as demonstrated in this commit:
Start a new project, ember addon
command defaults the version number to 0.0.0
.
Install ember-cli-release
and run ember release --premajor alpha
.
The readme says:
Increment the major SemVer version, and add given prerelease identifier with version of 0.
Thus, I expect the version to become 1.0.0-alpha.0
.
0.1.0
is released.
I don't know if this project is still active but it would be nice to be able to sign the tags created by ember release:
I could provide a PR for this if you think it would be a nice to have.
This is a big can of worms to open up, but there are a bunch of security issues in this project's dependencies (mostly mocha
and ember-cli
). Unfortunately, upgrading ember-cli
to the point where these issues are patched causes problems in this project's tests (which depend on now-removed private cli internals)
Since this package was originally written, the terminal I/O stuff has been extracted to console-ui, and a feature that ember-cli-release
's tests heavily rely on has been removed due to e-cli's own tests no longer needing it.
Through subclassing MockUI
(once obtained from console-ui
), we can get these back
function TestUI() {}
TestUI.prototype = new MockUI();
TestUI.prototype.waitForPrompt = function() {
if (!this._waitingForPrompt) {
var promise, resolver;
promise = new Promise(function(resolve){
resolver = resolve;
});
this._waitingForPrompt = promise;
this._promptResolver = resolver;
}
return this._waitingForPrompt;
};
TestUI.prototype.prompt = function(opts, cb) {
if (this._waitingForPrompt) {
this._waitingForPrompt = null;
this._promptResolver();
}
return MockUI.prototype.prompt.call(this, opts, cb);
}
I've spent a few hours digging really deep into this, and am at the point where we can no longer reliably mock answers to inquirer questions. Inquirer's own tests are a shining example of why mocking and stubbing out the whole world is a bad idea (tests aren't even run against real input/output streams, and use tons of testing helpers that aren't easily available to consumers). Because inquirer is a dependency of ember-cli (and we don't really interact with it directly), we're even farther removed from this thing that we need to alter in big ways to test effectively.
I have escalated this to the ember-cli team, and can resume working on this once I have an answer, and more OSS time
If beating inquirer into submission proves to time consuming or difficult, we should explore rewriting the tests in such a way that the console-ui is mocked entirely. This would be a regrettable, result of working with test-hostile dependencies of dependencies.
found 195 vulnerabilities (27 low, 112 moderate, 54 high, 2 critical)
Im on v1.0.0-beta.0
and this is my current config
/* jshint node:true */
/* var RSVP = require('rsvp'); */
var execSync = require('child_process').execSync;
module.exports = {
publish: true,
afterPublish: function(project, versions) {
// Publish dummy app with docs to gh-pages
runCommand('ember github-pages:commit --message "Released ' + versions.next + '"');
runCommand('git push origin gh-pages:gh-pages');
}
};
function runCommand(command) {
console.log('running: ' + command);
var output = execSync(command, { encoding: 'utf8' });
console.log(output);
}
When I ran ember release
it didnt publish or even go into the afterPublish hook.
master $> ember release
Warning: cannot specify option `publish` in config/release.js, ignoring
version: 1.13.13
Latest tag: v2.2.0
Successfully committed changes 'Released v2.2.1' locally.
[?] About to create tag 'v2.2.1' and push to remote 'origin', proceed?: Yes
Successfully created git tag 'v2.2.1' locally.
Successfully pushed 'v2.2.1' to remote 'origin'.
Successfully pushed 'master' to remote 'origin'.
Is there something im missing?
but package.json has a valid version (0.0.8)
This the last big PITA left in the release process (for me personally). Changelogs are only as helpful as they are readable, which makes them difficult to auto-generate.
Good changelog entires include:
The sanest path to generating entries is probably to go off of Github issues, or perhaps just merge commits (although integrating with Github could be beneficial for other reasons). Regardless, it would require introducing an editor step into the release process so that line items and meta information can be changed/added.
Another hurdle is how to handle changelogs for projects that maintain several stable branches, e.g. v1.13.x
, v2.0.x
, v2.x
. The changelog for the latest/default stable branch (master
) should include entries for all versions so that all releases are in one scannable place.
Could you please upgrade / loosen the dependency on npm
v3.5.x?
I was having an awful time trying to figure out why I was having a build problem regarding redefinition of __pfnDliNotifyHook2
in win_delay_load_hook.c
(part of node-gyp
) then I was told it was caused by a node-gyp
bug that was fixed like a year ago. Since I had a newer version of node-gyp and npm installed I couldn't figure out why it was happening. It turns out it was caused by ember-cli-release
since it pins its npm
version to 3.5.x, which pins node-gyp
to 3.2.x, which causes pain. See
nodejs/node-gyp#972 (comment)
This looks like a useful module even for non-ember-cli projects. Would be nice to pull out the core features into a regular npm module, with a bin (which could be used here, and this would be a lightweight wrapper).
npm WARN EBUNDLEOVERRIDE Replacing bundled ember-cli-release > npm > init-package-json with new installed version
npm WARN EBUNDLEOVERRIDE Replacing bundled ember-cli-release > npm > node-gyp with new installed version
npm WARN EBUNDLEOVERRIDE Replacing bundled ember-cli-release > npm > npm-install-checks with new installed version
npm WARN EBUNDLEOVERRIDE Replacing bundled ember-cli-release > npm > npmlog with new installed version
npm WARN EBUNDLEOVERRIDE Replacing bundled ember-cli-release > npm > read-package-json with new installed version
npm ERR! Darwin 15.2.0
npm ERR! argv "/Users/devinus/.anyenv/envs/ndenv/versions/v5.4.0/bin/node" "/Users/devinus/.anyenv/envs/ndenv/versions/v5.4.0/bin/npm" "install"
npm ERR! node v5.4.0
npm ERR! npm v3.3.12
npm ERR! path /Users/devinus/Projects/rebelmail-dashboard/node_modules/ember-cli-release/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js
npm ERR! code ENOENT
npm ERR! errno -2
npm ERR! syscall chmod
npm ERR! enoent ENOENT: no such file or directory, chmod '/Users/devinus/Projects/rebelmail-dashboard/node_modules/ember-cli-release/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js'
npm ERR! enoent This is most likely not a problem with npm itself
npm ERR! enoent and is related to npm not being able to find a file.
npm ERR! enoent
npm ERR! Please include the following file with any support request:
npm ERR! /Users/devinus/Projects/rebelmail-dashboard/npm-debug.log
This happens when running npm install
. When I remove ember-cli-release
from my package.json
the issue goes away. Any insights at all would be much appreciated. I'm stumped.
Most of the time, the version that is in package.json reflects the latest tag. However this is not the case when creating releases off of stable branches, e.g. the package version is 1.13.4
when the latest version is 2.3.1
. What ends up happening is that the next tag is calculated off of 2.3.1
, forcing the user to specify the tag manually with the --tag
option.
I can't think of an use case for not wanting to base the next version off of what is currently in package.json
. This would be a breaking change so would have to happen before 1.0.0
, although would likely not require action on the user's part.
A third current
key could be added to the hash passed to hooks, to give access to this version without breaking backwards compatibility.
Can you please apply #53 on top of version 0.2.8 and release as 0.2.9, please?
The fix is only in a 1.0.0 beta and users are complaining about a deprecation warning being there :(.
Ember-cli pins version to 0.2.9 but I can send a PR as soon as this is released.
Thank you!
I have this use case.
Latest version: v1.0.1
Succesfully committed changes 'Released v1.0.2' locally.
[?] About to create tag 'v1.0.2' and push to remote 'origin', proceed?: No
Aborted.
Commit ''Released v1.0.2' still there, even I said No.
So, can I ask before commit creates ?
Is this still actively maintained? I see the code hasn't changed in a couple years. I would love to give this some new life and take over maintenance under https://github.com/shipshapecode or https://github.com/html-next.
The release command doesn't seem to take into account the package-lock.json
introduced by npm 5. Running npm install
after running ember release
causes the package-lock.json to update with the newly released version. This should handled by the ember-cli-release
in some way.
Hello!
ember-cli-release seems to publish beta releases to npm under latest:
$ npm view ember-cli-release dist-tags
{ latest: '1.0.0-beta.2', zero: '0.2.9' }
For contrast ember-cli keeps the stable in latest.
$ npm view ember-cli dist-tags
{ latest: '2.8.0', beta: '2.9.0-beta.2' }
Could we avoid doing that since it makes it hard for dependency checkers to figure out what's the latest stable:
There have been a number of times that I have wanted a hook in config/release.js
that is called with the same arguments as beforeCommit
and afterPush
which allows me to prevent any modifications. This would be done just after step 3.
A few scenarios where this would be helpful:
master
is up to date with remote master
. If this is not true, the git push origin master
step fails, but only after already commiting and tagging locally. We should probably detect this scenario all the time (and not rely on a new hook), but it is a good example of why a hook would be useful.afterPush
process. Assume that you need to run a series of commands in afterPush
, and you want to avoid commiting/tagging/pushing if the local system isn't properly setup. ExampleMy thought was that if we added a preventRelease
hook you could return true
to prevent modifications. Something like:
module.exports = {
preventRelease: function(project, versions) {
// do something here to detect stuff
if (tharBeDragons) {
return true;
}
}
};
I am not very tied to the name preventRelease
(open to better suggestions).
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.