Coder Social home page Coder Social logo

ember-try's Introduction

ember-try

npm version GitHub Actions Build Status Ember Observer Score Build status Code Climate Test Coverage

An ember-cli addon to test against multiple dependencies, such as ember and ember-data.

Installation

ember install ember-try

Usage

This addon provides a few commands:

ember try:each

This command will run ember test or the configured command with each scenario's specified in the config and exit appropriately.

This command is especially useful to use on CI to test against multiple ember versions.

In order to use an alternate config path or to group various scenarios together in a single try:each run, you can use the --config-path option.

  ember try:each --config-path="config/legacy-scenarios.js"

If you need to know the scenario that is being run (i.e. to customize a test output file name) you can use the EMBER_TRY_CURRENT_SCENARIO environment variable.

ember try:one <scenario> (...options) --- <command (Default: ember test)>

This command will run any ember-cli command with the specified scenario. The command will default to ember test, if no command is specified on the command-line or in configuration.

For example:

  ember try:one ember-1.11-with-ember-data-beta-16 --- ember test --reporter xunit

or

  ember try:one ember-1.11-with-ember-data-beta-16 --- ember serve

When running in a CI environment where changes are discarded you can skip resetting your environment back to its original state by specifying --skip-cleanup=true as an option to ember try. Warning: If you use this option and, without cleaning up, build and deploy as the result of a passing test suite, it will build with the last set of dependencies ember try was run with.

  ember try:one ember-1.11 --skip-cleanup=true --- ember test

In order to use an alternate config path or to group various scenarios, you can use the --config-path option.

  ember try:one ember-1.13 --config-path="config/legacy-scenarios.js"

ember try:reset

This command restores all original files, and installs the original node modules again. For use if any of the other commands fail to clean up after (they run this by default on completion) or after running with ‘—skip-cleanup’.

ember try:ember <semver-string>

Runs ember test or the command in config for each version of Ember that is possible under the semver string given. Configuration follows the rules given under the versionCompatibility heading below.

ember try:config

Displays the configuration that will be used. Also takes an optional --config-path.

Config

versionCompatibility

If you're using ember-try with an Ember addon, there is a short cut to test many Ember versions. In your package.json under the ember-addon key, add the following:

  "ember-addon": {
    "versionCompatibility": {
       "ember": ">2.18.0 < 4.0.0"
    }
  }

The value for "ember" can be any valid semver statement. This will autogenerate scenarios for each version of Ember that matches the statement. It will also include scenarios for beta and canary channels of Ember that will be allowed to fail. These scenarios will ONLY be used if scenarios is NOT a key in the configuration file being used. If useVersionCompatibility is set to true in the config file, the autogenerated scenarios will deep merge with any scenarios in the config file. For example, you could override just the allowedToFail property of the ember-beta scenario.

To keep this from getting out of hand, ember-try will limit the versions of Ember used to the lasted point release per minor version. For example, ">1.11.0 <=2.0.0", would (as of writing) run with versions ['1.11.4', '1.12.2', '1.13.13', '2.0.0'].

Configuration Files

Configuration will be read from a file in your ember app in config/ember-try.js. Here are the possible options:

const getChannelURL = require('ember-source-channel-url');

module.exports = async function() {
  return {
    /*
      `command` - a single command that, if set, will be the default command used by `ember-try`.
      P.S. The command doesn't need to be an `ember <something>` command, they can be anything.
      Keep in mind that this config file is JavaScript, so you can code in here to determine the command.
    */
    command: 'ember test --reporter xunit',
    /*
      `npmOptions` - options to be passed to `npm`.
    */
    npmOptions: ['--loglevel=silent'],
    /*
      If set to true, the `versionCompatibility` key under `ember-addon` in `package.json` will be used to
      automatically generate scenarios that will deep merge with any in this configuration file.
    */
    useVersionCompatibility: true,
    /*
      If set to true, all npm scenarios will use `yarn` for install with the `--no-lockfile` option. At cleanup, your
      dependencies will be restored to their prior state.
    */
    useYarn: true,
    /*
      If set to true, all npm scenarios will use `pnpm` for install with the `--no-lockfile` options. At cleanup, your
      dependencies will be restored to their prior state.
    */
    usePnpm: true,

    /*
      buildManagerOptions allows you to opt-out of the default options such as `--ignore-engines --no-lockfile`.
      The buildManagerOptions function is aware of each scenario so you can customize your options.
    */
    buildManagerOptions(scenario) {
      return ['--ignore-engines'];
    }

    scenarios: [
      {
        name: 'Ember 2.11.0',
        /*
          `env` can be set per scenario, with environment variables to set for the command being run.
          This will be merged with process.env
       */
        env: {
          ENABLE_NEW_DASHBOARD: true
        },
        npm: {
          devDependencies: {
            'ember-source': '2.11.0'
          },
          /*
            You can optionally define npm or pnpm overrides to enforce a  specific dependency version
            to be installed. This is useful if other libraries you depend on include different
            versions of a package. This does nothing if `useYarn` is true;
          */
          overrides: {
            'lodash': '5.0.0'
          }
          /*
            When `useYarn` is true, you can optionally define yarn resolutions to enforce a
            specific dependency version to be installed. This is useful if other libraries
            you depend on include different versions of a package.
          */
          resolutions: {
            'lodash': '5.0.0'
          }
          /*
            In order to easily test multiple editions ember-try merges any `ember` property specified
            into the applications `package.json`. Values specified in the ember-try configuration will
            override values that pre-existed in the original `package.json`.
          */
          ember: {
            'edition': 'octane'
          }
        }
      },
      {
        name: 'Ember canary with Ember-Data 2.3.0',
        /*
          `allowedToFail` - If true, if this scenario fails it will not fail the entire try command.
        */
        allowedToFail: true,
        npm: {
          devDependencies: {
            'ember-data': '2.3.0',

            'ember-source': await getChannelURL('canary')

            // you can remove any package by marking `null`
            'some-optional-package': null
          }
        },
      },
      {
        name: 'ember-beta',
        npm: {
          devDependencies: {
            'ember-source': await getChannelURL('beta')
          }
        }
      },
    ]
  };
};

Scenarios are sets of dependencies. They can be specified exactly as in the package.json The name can be used to try just one scenario using the ember try:one command.

Yarn

If you include useYarn: true in your ember-try config, all npm scenarios will use yarn for install with the --no-lockfile option. At cleanup, your dependencies will be restored to their prior state.

Pnpm

If you include usePnpm: true in your ember-try config, all npm scenarios will use pnpm for install with the --no-lockfile options. At cleanup, your dependencies will be restored to their prior state.

⚠ pnpm versions from 8.0.0 to 8.6.x have the default value of resolution-mode setting changed to lowest-direct. This violates ember-try expectations as resolution-mode is expected to be highest, like in npm and pnpm versions < 8.0.0 and >= 8.7.0.

If you run into this issue, we recommend to upgrade pnpm to latest version. If you are unable to upgrade, you can set resolution-mode = highest in the .npmrc file.

A note on npm scenarios with lockfiles

Lockfiles are ignored by ember-try. (yarn will run with --no-lockfile and npm will be run with --no-package-lock and pnpm will be run with --no-lockfile). When testing various scenarios, it's important to "float" dependencies so that the scenarios are run with the latest satisfying versions of dependencies a user of the project would get.

Workspaces

If you include useWorkspaces: true in your ember-try config, ember-try will apply the diff to each individual workspace specified in package.json, allowing you to try scenarios in monorepo style repositories. See Yarn's documentation of workspaces for more details.

Video

How to use EmberTry

See an example of using ember-try for CI here, and the resulting build output.

Special Thanks

  • Much credit is due to Edward Faulkner The scripts in liquid-fire that test against multiple ember versions were the inspiration for this project.

Developing

  • Be sure to run npm link and npm link ember-try, otherwise any ember try commands you run will use the version of ember-try included by ember-cli itself.

ember-try's People

Contributors

backspace avatar barrythepenguin avatar bertdeblock avatar cibernox avatar dependabot-preview[bot] avatar dependabot-support avatar dependabot[bot] avatar dmuneras avatar ef4 avatar ember-tomster avatar hjdivad avatar kategengler avatar lolmaus avatar mansona avatar mike-north avatar mistahenry avatar nullvoxpopuli avatar odoe avatar oskarrough avatar polarctos avatar pzuraq avatar rwjblue avatar ryanto avatar sergeastapov avatar stefanpenner avatar taras avatar thoov avatar turbo87 avatar xcambar avatar xiphiasuvella avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

ember-try's Issues

ember-try fails with default addon app + ember-cli-sass

With a brand new addon blueprint from ember-cli 2.13.2, ember-try fails with this exception:

ENOENT: no such file or directory, scandir '/home/travis/build/blimmer/ember-cli-example-app-for-github/node_modules/node-sass/vendor'
Error: ENOENT: no such file or directory, scandir '/home/travis/build/blimmer/ember-cli-example-app-for-github/node_modules/node-sass/vendor'
    at Error (native)
    at Object.fs.readdirSync (fs.js:952:18)
    at Object.getInstalledBinaries (/home/travis/build/blimmer/ember-cli-example-app-for-github/node_modules/node-sass/lib/extensions.js:124:13)
    at foundBinariesList (/home/travis/build/blimmer/ember-cli-example-app-for-github/node_modules/node-sass/lib/errors.js:20:15)
    at foundBinaries (/home/travis/build/blimmer/ember-cli-example-app-for-github/node_modules/node-sass/lib/errors.js:15:5)
    at Object.module.exports.missingBinary (/home/travis/build/blimmer/ember-cli-example-app-for-github/node_modules/node-sass/lib/errors.js:45:5)
    at module.exports (/home/travis/build/blimmer/ember-cli-example-app-for-github/node_modules/node-sass/lib/binding.js:15:30)
    at Object.<anonymous> (/home/travis/build/blimmer/ember-cli-example-app-for-github/node_modules/node-sass/lib/index.js:14:35)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)

I noticed this on my project, ember-appboy with this PR: blimmer/ember-appboy#42

So I tried it with the default blueprint and experienced the same issue.

Proof of bad build:

https://travis-ci.org/blimmer/ember-cli-example-app-for-github/builds/234425340

Code:
https://github.com/blimmer/ember-cli-example-app-for-github/tree/bug/show-issue-with-nodesass

blimmer/ember-cli-example-app-for-github@e4dad0a

Version info:

 /tmp/ember-try-test   bug/show-issue-with-nodesass  ember version --verbose && npm --version && yarn --version
ember-cli: 2.13.2
http_parser: 2.7.0
node: 4.8.2
v8: 4.5.103.46
uv: 1.9.1
zlib: 1.2.11
ares: 1.10.1-DEV
icu: 56.1
modules: 46
openssl: 1.0.2k
os: darwin x64
4.6.1
0.24.5

Repro steps:

ember addon foo-bar --yarn true
cd foo-bar
ember install ember-cli-sass
# create tests/dummy/app/styles/app.scss with any content
# push to travis so it'll build

Fail fast strategy for JSHint/JSCS/ESLint tests

Just had the following happen: pushed a commit that accidentally had two consecutive blank lines in a file, which is a violation of a JSCS rule (ember-suave). The build took quite some time, just to show that a single JSCS test was failing for all ember versions (1.13 - 2.8 + beta + canary). Not only does this hamper developer productivity, it also puts a considerable amount of unnecessary burden on the CI infrastructure (Travis in this case).

Since JSHint/JSCS/ESLint tests won't depend on any dependencies, a) it seems unnecessary to run them in every try:each run and b) it could make sense to have them run once before any "real" tests.

So a "fail fast, fail early" strategy, which I guess is a pretty common CI best practice, could be in this case:

  1. run all JSHint/JSCS/ESLint tests with the default deps
  2. If that fails -> exit (non zero code)
  3. run try:each, with JSHint/JSCS/ESLint tests excluded

I guess you could make 1+3 happen with a custom config, not sure about 2? And what do you think about this approach, maybe this could become the default?

Add a hook for after successful test

It would be cool to hook into ember-try, for example to push the resulting build with ember-cli-deploy so a manual E2E test can be done.

So this hook should run after the build passes the tests, but before bower is reset. And optionally with an option to run even when the tests fail?

Fails when Bower is not globally installed.

This might seem obvious, but if the bower command is not available in $PATH we throw an error.

Ember CLI bundles bower itself (to avoid just this problem on ember init and ember new), so we should be able to tap into its bower install.


Discovered this due to ember-cli integration failures on Ember CLI's Windows CI system. Example output:

     Running: node_modules\ember-cli\bin\ember try:testall
version: 0.2.2--af1623b89b

events.js:85
      throw er; // Unhandled 'error' event
            ^
Error: spawn bower ENOENT
    at exports._errnoException (util.js:746:11)
    at Process.ChildProcess._handle.onexit (child_process.js:1053:32)
    at child_process.js:1144:20
    at process._tickCallback (node.js:355:11)

Ability to configure a minimum version for "testall"

Right now running ember try:testall goes all the way back to Ember 1.10 (as the earliest supported version). It would be nice to be able to configure ember-try to have a minimum version. For example, if your project/addon/whatever utlizes an HTMLbars spec that wasn't available until 1.11, testing against 1.10 will throw an error. However, I'd still like to be able to test all relevant versions with a single command, rather than having to specify them all individually.

Thoughts?

Allow using environment variables in command.

Specifically, I would like to be able to do things like this:

    {
      name: 'ember-alpha',
      command: 'SPECIAL_SAUCE=true ember test',
      bower: {
        dependencies: {
          'ember': 'alpha'
        },
        resolutions: {
          'ember': 'alpha'
        }
      }
    }

or:

ember try:one ember-alpha --- SPECIAL_SAUCE=true ember test

Ember-try uses `Yarn` in Travis CI Trusty Build

I've experienced the Travis build of my ember-addons throw errors when executing yarn install under ember try:one, the error is because it had troubles to access some of the private npm repos.

Although it is another concern, I was wondering the reason why my Travis build picked Yarn rather than NPM as the package manager. It turns out the condition has been configured as yarn.lock is present and yarn is installed globally since 0.2.12. In my repo I don't have yarn.lock but the fact is I'm using Trusty build of Travis (setting dist: trusty in .travis.yml) and Yarn was preinstalled there.

Is there any option we could set in ember-try to manually configure package managers between Yarn and NPM?

Deprecation warning for Ember CLI below v2.6.0

as reported in ember-cli/ember-cli#6058 ember-try is printing a deprecation warning even though the user project is using an Ember CLI release below v2.6.0, i.e. one that does not include ember-try.

before printing the deprecation warning we should check the ember-cli dependency and only print the warning if it's 2.6.0 or above.

`ember-try-config` messing with shrinkwrap

I have a project using npm shrinkwrap --dev and it's getting hung up on ember-try-config due to the fact that it is specified as latest. I keep getting errors that say that I have the wrong version, presumably because it's expected the version latest and I don't have a version that is literally called that.

npm ERR! Problems were encountered
npm ERR! Please correct and try again.
npm ERR! invalid: have [email protected] (expected: latest) /Users/alexlafroscia/Code/my-app/src/frontend/node_modules/ember-cli/node_modules/ember-try/node_modules/ember-try-config
npm ERR! extraneous: [email protected] /Users/alexlafroscia/Code/my-app/wwn/src/frontend/node_modules/ember-cli/node_modules/ember-try/node_modules/ember-try-config
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/alexlafroscia/Code/my-app/src/frontend/npm-debug.log

I know that we probably shouldn't be doing npm shrinkwrap --dev but that's out of my hands... Is there a possibility that you could specify that version differently?

Add API for removing packages

I see that this is on your radar #45 (comment)

packages in package.json cannot be removed. This needs further thought and perhaps our own configuration syntax

I just came across the need for this testing ember-data back before it was an npm package. Any API thoughts?

ember try:testall should honor all or a subset of 'ember test' arguments

ember try:testall --test-port $MY_TEST_PORT

The option '--test-port' is not registered with the try:testall command. Run `ember try:testall --help` for a list of supported options.

Background: we run multiple concurrent project tests on the same build machine, and our build system chooses a port and exposes it as an environment variable.

Allow scenarios without dependency changes

Currently, the ScenarioManager checks to ensure that there are dependency managers which are only created if you specify some sort of dependency change in your scenarios.

However, I have a use-case where I would like to run multiple different scenarios without changing any dependencies. This currently results in a No dependency manager adapter error being thrown. I can workaround this by specifying an empty dependency change (e.g., npm: {}), but this feels hacky.

So, I have two questions:

  1. Why is there a requirement that dependency managers must be present currently?
  2. Can we remove that requirement? It seems like answer should be yes since I can hack around it now anyway.

Command from config cannot include multiple command with | or &&

Currently one cannot configure to run multiple commands with one liners like:

command: 'npm uninstall X && ember test --filter unit'

Main issue being that commands are run with child_process.spawn and not with exec. I understand that spawn is used through out the addon but maybe there is something we could do about it?

Workaround: Move command into *.sh file and set it up to be run by ember-try.

command: "./my-script.sh"

Does `ember-try-config` need to be a dev dependency?

Hey ember-try devs,

I ran into an issue when trying to install a package that relied on ember-try (see below).
Does the ember-try-config package need to be a dependency for ember-try?

The following is taken from this issue: sir-dunxalot/ember-google-charts#22

$ ember install ember-google-charts                          
Cannot find module 'ember-try-config'
Error: Cannot find module 'ember-try-config'
    at Function.Module._resolveFilename (module.js:325:15)
    at Function.Module._load (module.js:276:25)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/Users/me/dev/frontend/node_modules/ember-cli/node_modules/ember-try/lib/utils/config.js:7:34)
    at Module._compile (module.js:397:26)
    at Object.Module._extensions..js (module.js:404:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)

I was able to install ember-google-charts by doing the following:

$ npm install ember-try-config
(...snip...)
$ ember install ember-google-charts

My current setup is:

  • ember-cli 2.6.1
  • npm 5.4.1

Add ability for `yarn` to replace `bower` executable

Would it be possible, if the bower executable was not found but yarn was, to use Yarn instead to install the alternate bower dependencies? I'm in the process of replacing npm with yarn for the CI setups in many of my addons, and realized that it would be nice to just forgot that bower exists entirely and use yarn for that too 😬

It seems like Bower support in Yarn is rocky right now, but after it stabilizes I'd be happy to add this support myself.

ember try is grabbing more than release/beta

When executing ember try:one ember-release --- ember test or ember try:one ember-beta --- ember test. Try is grabbing more than the release/beta. Ember release using 2.4.4+0947bfc3 (https://github.com/emberjs/ember.js/commits/0947bfc3), and Ember beta using 2.5.0-beta.4+2841986d (https://github.com/emberjs/ember.js/commits/2841986d).

Which as result causes this error:

Cannot convert undefined or null to object
TypeError: Cannot convert undefined or null to object
at Function.keys (native)
at _warnIfUsingStrippedFeatureFlags (/localdisk/workspace/ember-frost-core/bower_components/ember/ember-template-compiler.js:1529:25)
at /localdisk/workspace/ember-frost-core/bower_components/ember/ember-template-compiler.js:1547:5
at internalRequire (/localdisk/workspace/ember-frost-core/bower_components/ember/ember-template-compiler.js:98:16)
at requireModule (/localdisk/workspace/ember-frost-core/bower_components/ember/ember-template-compiler.js:44:14)
at /localdisk/workspace/ember-frost-core/bower_components/ember/ember-template-compiler.js:20781:1
at Object. (/localdisk/workspace/ember-frost-core/bower_components/ember/ember-template-compiler.js:20784:2)
at Module._compile (module.js:413:34)
at Object.Module._extensions..js (module.js:422:10)
at Module.load (module.js:357:32)
at Function.Module._load (module.js:314:12)
at Module.require (module.js:367:17)
at require (internal/module.js:16:19)
at Class.module.exports.included (/localdisk/workspace/ember-frost-core/node_modules/ember-cli-htmlbars-inline-precompile/index.js:17:20)
at EmberAddon. (/localdisk/workspace/ember-frost-core/node_modules/ember-cli/lib/broccoli/ember-app.js:413:15)
at Array.filter (native)

When using `ember try:each`, `npm install` doesn't always seem to be executed

I discovered that when using ember-try with npm overrides, that when I execute ember try:each it doesn't always invoke npm install between scenarios.

I've got two branches that demonstrate this problem.

The first branch demonstrates the problem: ember-try-broken. Here is a console log when the issue occurs: gist log. Search for "Missing npm packages" to find the errors.

To reproduce the problem, you should be able to checkout that branch, npm install && bower install, then run ember-try. You'll see the following error on every other scenario: Runnpm installto install missing dependencies.

Now I have a second branch that has a simple workaround to demonstrate this is the problem: ember-try-workaround. On this branch I have a custom ember-try command that effective does npm install && ember test. If you look at the commit 2d180a92 you can see how simple it is.

So based on those two branches, it seems the problem is that npm install is not properly called between scenarios. I'd be happy to try to fix this, but I don't even know where to begin.

[enhancement] Enable writing test results to file

I'm trying to publish the tap test results on Jenkins using the TAP plugin. For this, it would be great, to have a configuration option to have the output of the different runs of testall to be written into separate files. The rest could be handled by tap-merge and the Jenkins TAP plugin.

Removing ember-data causes error

Steps to reproduce:

  • ember addon foo
  • Remove ember-data from bower.json
  • rm -rf bower_components; bower i
  • ember try default test

And you will get this error:
screen shot 2015-07-17 at 12 25 53 pm

Failing on Travis

I updated an addon's test suite and the build began failing on Travis with the following error:

The command "ember try $EMBER_TRY_SCENARIO test" exited with 1.

The test suite is passing locally. I have replicated the issue with versions 0.0.6 and 0.0.7 of this addon.

Is this a problem on your end or mine?

Thanks!

New version?

A few bugs have been fixed, and I'd love a new version published to take advantage of them.

Also, I'd like to get this integrated into Ember CLI's default addon setup, and we can't rely on a git SHA (due to non-git users).

Evergreen ember release testing

It would be nice to be able to specify an ember-try/travis config that tests the latest patch version of all minor ember releases above a certain specified one. As a maintainer of several plugins, it is easy for them to slip into a state where they are testing a minor version, and ember-release, but missing a minor version or two in between.

Killing ember-try while it's running leaves bower.json modified

Scenario

I have a hanging test, and I kill ember-try with ctrl-c. My bower.json is left in a state where my scenario is still applied

Suggestions

  1. We find a way to have ember-try clean up after its self upon teardown
  2. We add a command to ember-try, to easily restore the project's original bower.json

Allow testing of `beta` and `canary` versions.

I would like the following configuration to work:

module.exports = {
  scenarios: [
    {
      name: 'ember-release',
      dependencies: {
        "ember": "components/ember#release"
      }
    },
    {
      name: 'ember-beta',
      dependencies: {
        "ember": "components/ember#beta"
      }
    },
    {
      name: 'ember-canary',
      dependencies: {
        "ember": "components/ember#canary"
      }
    }
  ]
};

Currently this throws an error in lib/utils/scenario-manager.js#L32 because the version actually contains the SHA:

Error: Versions do not match: 1.13.0-beta.1+canary.8e8b3326 expected: components/ember#canary

Thoughts on allowing this warning to be opted out of in the case that the version specified in dependencies is not a valid "SemVer" version number?

Having trouble figuring out how to try versions of ember-data

Howdy,
I have a scenario like this

    {
      name: 'ember-data-2.5',
      bower: {
        devDependencies: {
          'ember': 'components/ember#2.10.2'
        },
        resolutions: {
          'ember': '2.10'
        }
      },
      npm: {
        devDependencies: {
          'ember-data': 'emberjs/data#2.5.5'
        },
        resolutions: {
          'ember-data': '2.5.5'
        }
      }
    },

and I get errror like this:

22.61s$ ember try:one $EMBER_TRY_SCENARIO test --skip-cleanup
npm ERR! git rev-list -n1 2.5.5: fatal: ambiguous argument '2.5.5': unknown revision or path not in the working tree.
npm ERR! git rev-list -n1 2.5.5: Use '--' to separate paths from revisions, like this:
npm ERR! git rev-list -n1 2.5.5: 'git <command> [<revision>...] -- [<file>...]'

[enhancement] Handle ember and ember data as addons

Ember data 2.3 will be an ember-cli addon and ember will follow. Supporting dependencies in package.json as well as in bower.json would help handling this new development.

As before, I could try to get my hands dirty, but I'm not aware if there's already anything done in that direction.

Running command silently contains ember-try installation output

I'm writing a scenario to test internal, unpublished dependencies and running the following command in our CI environment:

ember try:one development --- ember test -r xunit --silent > test-log.xml

This seemingly runs without issue, but when we try to parse that file, we find that some ember-try output is appended and prepended to the file.

bower ember#~2.8.0              cached https://github.com/components/ember.git#2.8.1
...more bower installation output...

...xunit xml output...

...more bower rollback output....
bower jquery#>=1.8.3                                       cached https://github.com/jquery/jquery-dist.git#3.1.1

I'm happy to dig into this. Just wanted to put it out there if anyone else had ideas on what this could be.

Add a parameter to the scenarios to warn on failure instead of fail

I think a useful idea would be to add a parameter to the scenarios where for a particular scenario you would warn if there was a failure instead of actually failing. This way the travis build doesn't fail if the project relies on a release ember version, when the canary ember version causes a test failure.

Deprecation warning for Ember CLI below v2.6.0

as reported in ember-cli/ember-cli#6058 ember-try is printing a deprecation warning even though the user project is using an Ember CLI release below v2.6.0, i.e. one that does not include ember-try.

before printing the deprecation warning we should check the ember-cli dependency and only print the warning if it's 2.6.0 or above.

Table cell width / alignment issues in some scenarios.

Example from a ember try:testall in ember-test-helpers:

Scenario ember-release: SUCCESS
┌────────────────────┬────────────────────┬──────────────────────────────┬──────────┐
│ Dependency         │ Expected           │ Used                         │ Type     │
├────────────────────┼────────────────────┼──────────────────────────────┼──────────┤
│ ember              │ components/e… │ 2.3.0+941794ac               │ bower    │
├────────────────────┼────────────────────┼──────────────────────────────┼──────────┤
│ ember-data         │ ~2.2.0             │ 2.2.1                        │ bower    │
└────────────────────┴────────────────────┴──────────────────────────────┴──────────┘

Scenario ember-beta: SUCCESS
┌────────────────────┬────────────────────┬──────────────────────────────┬──────────┐
│ Dependency         │ Expected           │ Used                         │ Type     │
├────────────────────┼────────────────────┼──────────────────────────────┼──────────┤
│ ember              │ components/e… │ 2.4.0-beta.1+7fbca9c0        │ bower    │
├────────────────────┼────────────────────┼──────────────────────────────┼──────────┤
│ ember-data         │ ~2.2.0             │ 2.2.1                        │ bower    │
└────────────────────┴────────────────────┴──────────────────────────────┴──────────┘

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.