angular-cn/.codefresh
Pete Bacon Darwin 9f54d76ef5 refactor(upgrade): use Bazel packages to avoid symlinks in the source (#29466)
Previously we had to share code between upgrade/dynamic and upgrade/static
by symlinking the `src` folder, which allowed both packages to access
the upgrade/common files.

These symlinks are always problematic on Windows, where we had to run
a script to re-link them, and restore them.

This change uses Bazel packages to share the `upgrade/common` code,
which avoids the need for symlinking the `src` folder.

Also, the Windows specific scripts that fixup the symlinks have also
been removed as there is no more need for them.

PR Close #29466
2019-04-02 10:38:01 -07:00
..
Dockerfile.win-1809 ci: add codefresh (#29305) 2019-03-21 22:19:19 +00:00
README.md ci: add codefresh badge (#29475) 2019-03-25 09:23:48 -07:00
bazel.rc build: Remove --watchfs from bazelrc file (#29635) 2019-04-01 14:57:30 -07:00
codefresh.yml refactor(upgrade): use Bazel packages to avoid symlinks in the source (#29466) 2019-04-02 10:38:01 -07:00
fix-msys64.cmd ci: add codefresh (#29305) 2019-03-21 22:19:19 +00:00

README.md

CodeFresh configuration

Codefresh build status

This folder contains configuration for the CodeFresh based CI checks for this repository.

The build pipeline

CodeFresh uses a several pipeline for each repository. The codefresh.yml file defines pipeline build steps for this repository.

Run results can be seen in the GitHub checks interface and in the public pipeline

Although most configuration is done via pipeline.yml, some options are only available in the online pipeline settings, which needs a login to access.

Caretaker

CodeFresh status can be found at http://status.codefresh.io/.

Issues related to the CodeFresh setup should be escalated to the Tools Team via the current caretaker, followed by Alex Eagle and Filipe Silva.

Rollout strategy

Currently it is only used for tests on Windows platforms, on the master branch, and without pushing user-facing reports. It's only possible to see current builds in the public pipeline dashboard.

After a week or two of running like this, we should reassess how stable and reliable it is.

Next steps include:

  • building PRs
  • showing build status publicly
  • blocking PRs that break the build
  • expanding the test suite