In #17060, the `deploy-code` job was updated to [include][1] the
`init_environment` custom command. This caused the job to start failing,
because the `init_environment` command was not compatible with the
`cloud-sdk` executor used in `deploy-code`. There were two problems:
1. The `init_environment` command assumes that the working directory is
`~/ng`. The `cloud-sdk` executor [did not specify][2] a working
directory.
Example failures:
- On master:
https://app.circleci.com/pipelines/github/angular/angular.js/
152/workflows/812df7b2-4bba-4e9e-a868-8c58db5d40d1/jobs/1594
- On v1.8.x:
https://app.circleci.com/pipelines/github/angular/angular.js/
153/workflows/6a9826ac-d191-4042-8c39-0c969c81e381/jobs/1607
2. The `install_java` step, which is part of the `init_environment`
command, relies on `sudo`, which is not available in the `cloud-sdk`
executor.
Example failure:
- [On a PR]:
https://app.circleci.com/pipelines/github/angular/angular.js/
160/workflows/2eed5cfa-751c-44ba-b825-1d6cd5ba3406/jobs/1660
This commit fixes the issues by:
1. Specifying a working directory for the `cloud-sdk` executor. It also
updates paths used in other steps of the `deploy-code` job to take
the working directory into account.
2. Removing the `install_java` step from the `init_environment` command
and adding it explicitly to jobs than require it.
[1]: https://github.com/angular/angular.js/blob/83f084e5db95768dcee5/.circleci/config.yml#L359
[2]: https://github.com/angular/angular.js/blob/83f084e5db95768dcee5/.circleci/config.yml#L34-L37
Previously, the `grunt prepareDeploy` command was run in both the
`prepare-deployment` and `deploy-docs` CI jobs. The reason was that not
all files affected by `grunt prepareDeploy` were persisted to the
workspace across jobs.
More specifically, the command would affect files in the `deploy/` and
`scripts/docs.angularjs.org-firebase/` directories and also create a
`firebase.json` file at the root directory, but only the `deploy/`
directory was [persisted to the workspace][1].
This commit avoids unnecessarily running the `grunt prepareDeploy`
command in the `deploy-docs` CI job by ensuring that all affected files
will be persisted to the workspace in the `prepare-deployment` CI job,
which always runs before `deploy-docs`.
[1]: https://github.com/angular/angular.js/blob/295213df953766625462/.circleci/config.yml#L265Closes#17060
Previously, the generated build artifacts and docs were only deployed
for builds associated with the master branch. There was also a `latest`
branch mentioned in the config, but there is normally no such branch, so
this had no effect.
This commit fixes the rules so that deployments happen when necessary.
More specifically:
- The `deploy-code` job now runs for builds associated with:
- The master branch.
- The stable branch (i.e. the branch from which the version tagged as
`@latest` on npm is released).
- Tags of the form `v1.X.Y(-Z)`. (This also required configuring
CircleCI to run builds for git tags, which does not happen by
default.)
- The `deploy-docs` job now runs for builds associated with:
- The stable branch (i.e. the branch from which the version tagged as
`@latest` on npm is released).
The new rules for when deployments should take place are based on the
logic previously in [.travis.yml][1] and [scripts/travis/build.sh][2]
(from before we switched from Travis to CircleCI).
[1]: https://github.com/angular/angular.js/blob/974700af7c1/.travis.yml#L54-L103
[2]: https://github.com/angular/angular.js/blob/974700af7c1/scripts/travis/build.sh#L66-L101
As mentioned in `RELEASE.md`, now that the [CDN][1] has been updated
with the 1.8.0 version, it is safe to bump the value of the
`branchVersion` property in `package.json` to `^1.8.0`. This will cause
the docs app to use the latest version, namely 1.8.0.
[1]: https://ajax.googleapis.com/ajax/libs/angularjs/1.8.0/angular.js
Due to COVID-19 affecting teams migrating from AngularJS, the Long Term Support period has been
extended by 6 months (until the end of 2021). See announcement on Twitter:
https://twitter.com/angular/status/1287780634572857357
This commit updates the "Version Support Status" page to also mention the extension.
Partially addresses #17058.
The `indexBy()` method was renamed to `keyBy()` in lodash v4 (see
lodash/lodash@b1d52ccd82). This commit
updates all usages of `indexBy()` to `keyBy()`.
If `ngSanitize` is added as a module dependency and a Content-Security-Policy
is set that does not allow inline styles then Firefox and Chrome show the
following message:
> Content Security Policy: The page’s settings observed the loading of a
resource at self (“default-src”). A CSP report is being sent.
This message is caused because AngularJS is creating an inline style tag
to test for a browser bug that we use to decide what sanitization strategy
to use, which causes CSP violation errors if inline CSS is prohibited.
This test is no longer necessary, since the `DOMParser` is now safe to use
and the `style` based check is redundant.
In this fix, we default to using `DOMParser` if it is available and fall back
to `createHTMLDocument()` if needed. This is the approach used by DOMPurify
too.
The related unit tests in `sanitizeSpec.js`, "should not allow JavaScript
execution when creating inert document" and "should not allow JavaScript
hidden in badly formed HTML to get through sanitization (Firefox bug)", are
left untouched to assert that the behavior hasn't changed in those scenarios.
Fixes#16463.
Previously, the docs app used `document.write()`, causing the following
warning on Chrome:
```
A parser-blocking, cross site (i.e. different eTLD+1) script,
https://ajax.googleapis.com/ajax/libs/angularjs/1.7.9/angular.min.js, is
invoked via document.write. The network request for this script MAY be
blocked by the browser in this or a future page load due to poor network
connectivity.
```
In the past, `document.write()` seems to have been used in order for
browsers (such as Firefox) to work correctly with our dynamically set
`<base>` tag and relative style/script URLs.
This commit replaces `document.write()` with regular
`<style>`/`<script>` tabs to avoid the warning (and potential issues due
to poor network connectivity). It seems that the latest versions of
Chrome, Firefox and IE can handle this fine (without naticeable delays).
Fixes#15396
Create style elements and modify their text content instead of using
innerHTML to create the whole `<style>` element with its content.
That way style insertion done at bootstrap time doesn't interfere with
Trusted Types restrictions in Chrome (https://bit.ly/trusted-types).
Remove the type attribute - `text/css` is default:
https://html.spec.whatwg.org/#update-a-style-block.
Closes#17014
This commit gets rid of all references to Travis and, belatedly, Jenkins.
Now all CI is done on CircleCI and releases are run locally.
The CI no longer updates the docs and code.angularjs.org for jobs that are
not on the `master` branch.
During releases, the docs and code should be uploaded manually.
Node.js 8 ends its support at the end of 2019. Node 12 will be supported
until April 2022 which is way past AngularJS end of support.
Some dependencies needed to be updated to make them work in Node.js 12.
The files served for the various versions on https://code.angularjs.org/
are retrieved by a Firebase function from a Firebase Storage bucket
(where they are deployed to from Travis CI). The files are stored
exactly as they are named on disk.
It turns out that some of the files have names with special characters
that get URI-encoded when sent to the Firebase function. For example,
`input[text].html` becomes `input%5Btext%5D.html`. As a result, the
actual file cannot be retrieved from the Storage bucket (since the name
does not match) and `index.html` is returned instead. Apparently, this
never worked, but nobody noticed or reported it until recently.
An example of a failing URL is:
https://code.angularjs.org/1.7.9/docs/api/ng/input/input%5Btext%5D
(NOTE: https://docs.angularjs.org/ works correctly, since the files are
deployed to Firebase hosting directly and not to a Storage bucket.)
This commit fixes the problem by decoding the request path before trying
to retrieve the corresponding file from the Storage bucket.
Closes#16943
The currently latest-1 version of desktop Safari (v12.0) on SauceLabs is
completely unstable. Switching to the latest version (currently v12.1),
which works fine.
Closes#16888
George Kalpakas
dependabot[bot]
Ewa G
Harri Lehtola
Pete Bacon Darwin
Eran Nussbaum
Michał Gołębiowski-Owczarek
Krzysztof Kotowicz
Nishant Mittal
Sam Katakouzinos
Chives
comet
thatshubham
Angel_Kitty