Old issues

[brettz9]

Hi,

Would you be able to delete jquery-deferred-integration, setver-removal, and update-records branches? Was just checking that everything had been integrated and saw these still around.

FYI, I have a PR coming to improve the docs, so I wouldn't bother your updating gh-pages (which I mention in case you were otherwise going to be inclined to do this while handling the other old branches).

[mikemorton]

Do you mean to say that you're planning to update gh-pages? If so that'll be awesome because it's still the first result on a google search for db.js

[brettz9]

That (and its timing) is @aaronpowell 's call. I do have some more PR's coming which are to update the docs a bit further, but I'm not sure of Aaron's release cycle, and we do have a good number of changes now in the README that would seem to me to be ripe for display. I've updated the issue title to request this as well.

[brettz9]

As a gentle summary reminder (related to clean-up), which I can try to keep up to date here:

1. Other issues that can be closed: Does db.js support the creation of multi-segment indexes? #40, Searching using a compound index possible? #46, Upgrade causes event.currentTarget undefined with IndexedDBShim #87, There is no way to test if the db.js is upgraded #109, index["openKeyCursor"] is undefined #157
2. Answer question on whether to change to jQuery.Deferred() in thenable testing file to avoid need for JSON file?
3. Issues still requiring action on your part but are related to clean-up rather than coding: Chrome: db.open().done is not a function #119 (gh-pages)
4. PRs 183-185

[brettz9]

Also, FYI, when I run the "npm test" grunt tasks, I'm getting a "Error closing tunnel" for the tunnel to Sauce Labs....In PR #160 I've commented it out--not sure if you can fix things with your key to avoid it needing to be commented out.

[brettz9]

I've set up my own Travis account (still working on Saucelabs). However, in order to allow me (or others) to do this in a maintainable manner, I'd suggest either putting .travis.yml in .gitignore or keep it in Git but remove its env section and manually add these within your Travis account. Would you be open to a PR using either approach?

[brettz9]

What is the advantage and need for Saucelabs vs. Karma vs. PhantomJS? I understand Mocha is for the unit tests, but I just don't have a clear idea of why all the rest (and not just one) are needed for browser testing.

[aaronpowell]

I've just done a change that changes the saucelabs integration, now it will only try and do it if it's not a PR (running on your machine won't be a PR 😉) and there is a key set as an env variable (which you can do in your shell easy enough).

[aaronpowell]

Regarding ignoring the yml file, that won't really solve anything, the way PR's are handled by Travis means that builds will use my settings always, but they restrict secure variables to only be accessible to pushes to this repo.

[brettz9]

Right re: yml file, but if you go to "More Options"->"Settings" while logged into your repo on Travis, you will see an ENVIRONMENTAL VARIABLES section where you can privately store the values of sauceuser and saucekey. That is what I am doing, and if you do it on your Travis account, it can work without putting the env't variables inside of the tracked yml file.

[aaronpowell]

To your last question - Sauce Labs integration was added a few years back, when travis didn't support UI testing, but also my intention was to test multiple browsers (Chrome, FF, Safari and IE, maybe even mobile). Admittedly I'm not using it to its full potential, once I get my account setup for OSS then I'll look to expand.

But it's not really practical for local development, the feedback loop is not ideal so I'd been wanting an easy way to do local testing which didn't just involve refreshing the browser (which has been the staple). This is why I'd been wanting to get PhantomJS going, it's faster than using Selenium WebDriver. To run it I needed an easy solution which is Karma.

Hopefully that explains the thought process behind the variety of tools for testing.

[aaronpowell]

Sure, I've seen the settings in Travis, but ultimately it won't solve the PR issue, and I don't want there to be an expectation of having to create a Sauce Labs account to contribute.

The payoff here would for the people who setup Travis on their own fork, which I assume you've done?

[brettz9]

As far as Travis, yes, I've set it up on my own fork, and it is nice to see that there without polluting your site before things are ready.

I see your point about not wanting to require a Sauce Labs account though. How about checking first for the commonly used sauce environmental variable names, and defaulting to the ones you set up in .travis.yml?

    var saucekey = process.env.SAUCE_ACCESS_KEY || process.env.saucekey

and

    options: {
        username: process.env.SAUCE_USERNAME || process.env.sauceuser,
        // ...
    }

That way, saucekey and sauceuser from travis.yml won't negate the effects and overwrite my own environmental variables on my own Travis account.