The ember-cli-release from shipshapecode

Bring `--prerelease` to config file

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.

feat: Signing the tag

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:

https://git-scm.com/book/uz/v2/Git-Tools-Signing-Your-Work#Signing-Tags

I could provide a PR for this if you think it would be a nice to have.

Publishing with --prerelease should create the appropriate tag

ember release --prerelease beta

This should publish to npm with a beta tag

npm publish --tag beta

Remove ember deprecation warning and release as 0.2.9

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!

Hook to update versions of additional files?

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?

Untracked files added to commit when tree modified

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.

Maintainers

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.

Ember deprecation warning

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`

Ask before create commit.

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 ?

Add `preventRelease` hook.

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:

Ensuring that local 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.
Ensuring that the local system is setup for 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. Example

My 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).

Publish example does not work

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.

Introduction to ember-cli-release at Global Ember Meetup

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's use case for the addon?
How to get stated using it?
What should the user be aware of?

What do you think?

Using without ember-cli

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).

Support for prelease versions like 1.0.0-beta.1

See https://github.com/npm/node-semver#prerelease-identifiers

Dependencies becoming woefully out-of-date

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

Action required: Greenkeeper could not be activated 🚨

🚨 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.

Skipping CircleCI build

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?

Removes trailing newline in package.json

Not that big of a deal, but it would be nice to avoid changing the whitespace, as demonstrated in this commit:

tildeio/htmlbars@a5bb78d

Generate changelog entries

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:

Scannable formatting
Tag name
Human readable date
Aggregated changes
- Concise explanations
- References (i.e. Github issue links)
- Attributions (i.e. Github handles)
Meta information
- Breaking changes
- Upgrade instructions

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.

Yellow message not friendly to light theme

😢

This addon seems to be unmaintained - alternative: ember-cli-release-tag

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:

The 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.
NPM publishing is not included right now
For semver, 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'
You have to confirm before the release commit is created (see #67)

See #71 , #72, #69

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.

Fail on push with pre-push hook

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 )?

Don't do anything before confirmation

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.

Base next semver tag off of version in package.json instead of latest

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.

Take into account package-lock.json/support npm 5

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.

Could we keep the beta of ember-cli-release out of "latest" on npm?

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:

raineorshine/npm-check-updates#285 (comment)

Invalid Version: * TypeError: Invalid Version: *

but package.json has a valid version (0.0.8)

NPM Publish in release.js config not working

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?

"Skipped tagging, HEAD already at tag: v0.1.0"

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?

Using old npm forces old node-gyp -> makes windows build problems

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)

Getting weird error when npm installing

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.

How to create a full-fledged GitHub release

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?

Add version to release.js

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).

Error while installing v1.0.0-beta.1

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'

`ember release --premajor alpha` unexpected behavior with initial version 0.0.0

Steps to reproduce

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.

Expected

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.

Actual

0.1.0 is released.

>=0.2.4 breaks ember-cli tests

See:

ember-cli/ember-cli#4891
ember-cli/ember-cli#4958

npm dependency version creates conflict with `np` tool

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).

[Security] Fix 195 known vulnerabilities

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)

Don't use private internals of packages you depend on

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);
}

Inquirer is annoying

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

Backup plan

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)

shipshapecode / ember-cli-release Goto Github PK

ember-cli-release's People

Contributors

Stargazers

Watchers

Forkers

ember-cli-release's Issues

Steps to reproduce

Expected

Actual

Don't use private internals of packages you depend on

Inquirer is annoying

Backup plan

Recommend Projects

Recommend Topics

Recommend Org