mirror of
https://github.com/zed-industries/zed.git
synced 2025-01-07 17:26:56 +00:00
Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
13c14d9b96
This PR updates Danger to proxy its requests to GitHub through a proxy service. ## Motivation Currently Danger is not able to run on PRs opened from forks of Zed. This is due to GitHub Actions' security policies. Forks are not able to see any of the repository secrets, and the built-in `secrets.GITHUB_TOKEN` has its permissions [restricted](https://docs.github.com/en/actions/security-guides/automatic-token-authentication#permissions-for-the-github_token) to only reads when running on forks. I asked around on the Danger repo, and some big projects (DefinitelyTyped) are working around this by using a publicly-listed (although slightly obfuscated) token: https://github.com/danger/danger-js/issues/918#issuecomment-2048629487. While this approach is _probably_ okay given the limited scope and permissions of the GitHub token, I would still prefer a solution that avoids disclosing the token at all. ## Explanation I ended up writing a small proxy service, [Danger Proxy](https://github.com/maxdeviant/danger-proxy), that can be used to provide Danger with the ability to make authenticated GitHub requests, but without disclosing the token. From the README: > Danger Proxy will: > > - Proxy all requests to `/github/*` to the GitHub API. The provided GitHub API token will be used for authentication. > - Restrict requests to the list of repositories specified in the `ALLOWED_REPOS` environment variable. > - Restrict requests to the subset of the GitHub API that Danger requires. I have an instance of this service deployed to [danger-proxy.fly.dev](https://danger-proxy.fly.dev/). Release Notes: - N/A |
||
|---|---|---|
| .cargo | ||
| .config | ||
| .github | ||
| .zed | ||
| assets | ||
| crates | ||
| docs | ||
| extensions | ||
| script | ||
| tooling/xtask | ||
| .dockerignore | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .mailmap | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| debug.plist | ||
| docker-compose.sql | ||
| docker-compose.yml | ||
| Dockerfile | ||
| LICENSE-AGPL | ||
| LICENSE-APACHE | ||
| LICENSE-GPL | ||
| livekit.yaml | ||
| Procfile | ||
| README.md | ||
| rust-toolchain.toml | ||
| typos.toml | ||
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
You can download Zed today for macOS (v10.15+).
Support for additional platforms is on our roadmap:
- Linux (tracking issue)
- Windows (tracking issue)
- Web (tracking issue)
For macOS users, you can also install Zed using Homebrew:
brew install zed
Alternatively, to install the Preview release:
brew tap homebrew/cask-versions
brew install zed-preview
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.