The previous solution for opening Plunkers from the docs relied on tight
coupling between the docs site and the plunkr site, in particular the
URL to the example code on the docs server was hard coded in the Plunker
site.
This change goes back to the old POST method of creating a Plunker, but
with a subtle difference: In the very old docs, the content was injected
directly into the example HTML at build time. This was easy enough to
do as the example actually ran in the current page but also increased
the size of the doc page.
The new examples are run in completely separate iframes. This new version
of showing a Plunker loads the file content for the Plunker from the
server by accessing the example's manifest.json file using $http requests.
This also has the additional benefit that you can now generate plunkers
from examples that are running locally or, frankly, in any folder on any
server, such as personal builds on the Jenkins CI server.
Closes#7186Closes#7198
The "runnableExample.template.html" template overrides the one in the
dgeni-packages "examples" package with a similar template that also has
a link to a special Plunker URL that can pull in the example from our
code.angularjs.org website.
The docs were relying on the grunt/util module for getting version info
but this was unreliable and full of custom regexes. This is moved into
a new version-info module that makes much better use of the semver library.
Use the multiConfiguration ability of Protractor to start tests on multiple browsers
from the same travis cell. Group tests by type (jquery, jqlite, or docs tests) instead
of by browser. Turn on tests for jQuery.
Update to the latest dgeni-packages, which supports multiple
deployment environments for the examples.
Add a jQuery deployment environment for the examples.
Currently, the target of the runnable example iframe always points
to the default deployment environment, not to the environment under
which the main app is running.
Closes#6361
This got missed in the doc migration: When there is an error in an
Angular app, extra information is placed in the URL, which can be used
by the docs application to display a more useful message.
This fix adds that back in. The error message templates are extracted
by the minerr tool during build and put into the errors.json file. The
errors-doc processor will load this up and attach these message templates
to the error docs.
The display of these templates was already in place, via the errorDisplay
directive in docs/app/js/errors.js.
(Also, moved the error.template.html file into the angular.js repository
from the dgeni-packages repository as this is specific to the angular.js
project and all the other error related stuff is in here.
Finally, also, added an e2e test that checks that minerr formatted
messages are displayed correctly.
Closes#6363
