angular-docs-cn/.circleci
Paul Gschwendtner 363e1ab775 ci: ensure saucelabs browsers can load karma test page (#35171)
In the past we had connecitivity issues on Saucelabs. Browsers on
mobile devices were not able to properly resolve the `localhost`
hostname through the tunnel. This is because the device resolves
`localhost` or `127.0.0.1` to the actual Saucelabs device, while it
should resolve to the tunnel host machine (in our case the CircleCI VM).

In the past, we simply disabled the failing devices and re-enabled the
devices later. At this point, the Saucelabs team claimed that the
connecitivy/proxy issues were fixed.

Saucelabs seems to have a process for VMs which ensures that requests to
`localhost` / `127.0.0.1` are properly resolved through the tunnel. This
process is not very reliable and can cause tests to fail. Related issues have been
observed/mentioned in the Saucelabs support docs. e.g.

https://support.saucelabs.com/hc/en-us/articles/115002212447-Unable-to-Reach-Application-on-localhost-for-Tests-Run-on-Safari-8-and-9-and-Edge
https://support.saucelabs.com/hc/en-us/articles/225106887-Safari-and-Internet-Explorer-Won-t-Load-Website-When-Using-Sauce-Connect-on-Localhost

In order to ensure that requests are always resolved through the tunnel,
we add our own domain alias in the CircleCI's hosts file, and enforce that
it is always resolved through the tunnel (using the `--tunnel-domains` SC flag).
Saucelabs devices by default will never resolve this domain/hostname to the
actual local Saucelabs device.

PR Close #35171
2020-02-06 15:36:27 -08:00
..
README.md build: use bazel version from node modules (#26691) 2018-10-30 16:19:13 -04:00
bazel.common.rc refactor: simplify bazel saucelabs targets using karma pre-test wrapper and shared saucelabs connection between tests (#34769) 2020-01-28 13:47:00 -08:00
bazel.linux.rc ci: move setup of bazel configurations into the env init scripts (#34834) 2020-01-22 14:37:02 -05:00
bazel.windows.rc ci: always set up RBE for bazel executions on CI (#34834) 2020-01-22 14:37:02 -05:00
config.yml ci: ensure saucelabs browsers can load karma test page (#35171) 2020-02-06 15:36:27 -08:00
env-helpers.inc.sh ci(docs-infra): use the tests from the stable branch in `aio_monitoring_stable` CircleCI job (#30110) 2019-04-26 16:33:45 -07:00
env.sh ci: ensure saucelabs browsers can load karma test page (#35171) 2020-02-06 15:36:27 -08:00
gcp_token ci: update gcp_token (#31405) 2019-07-03 08:54:02 -07:00
get-commit-range.js ci: work around `CIRCLE_COMPARE_URL` not being available wih CircleCI Pipelines (#32537) 2019-09-09 12:21:44 -04:00
github_token ci: re-encrypt .circleci/github_token (#26698) 2018-10-23 13:31:48 -07:00
setup_cache.sh Revert "build: update to newer circleCI bazel remote cache proxy (#25054)" (#25076) 2018-07-24 16:05:58 -07:00
trigger-webhook.js ci(docs-infra): manually trigger the preview server webhook (#27458) 2018-12-04 13:59:54 -08:00
windows-env.ps1 build: migrate to node@12.14.1 (#34955) 2020-01-27 09:31:22 -08:00

README.md

Encryption

Based on https://github.com/circleci/encrypted-files

In the CircleCI web UI, we have a secret variable called KEY https://circleci.com/gh/angular/angular/edit#env-vars which is only exposed to non-fork builds (see "Pass secrets to builds from forked pull requests" under https://circleci.com/gh/angular/angular/edit#advanced-settings)

We use this as a symmetric AES encryption key to encrypt tokens like a GitHub token that enables publishing snapshots.

To create the github_token file, we take this approach:

  • Find the angular-builds:token in http://valentine
  • Go inside the CircleCI default docker image so you use the same version of openssl as we will at runtime: docker run --rm -it circleci/node:10.12
  • echo "https://[token]:@github.com" > credentials
  • openssl aes-256-cbc -e -in credentials -out .circleci/github_token -k $KEY
  • If needed, base64-encode the result so you can copy-paste it out of docker: base64 github_token