ci: gate PR builds on ready-for-review, split backport control into need-backport (#1630)

ci: gate PR builds on draft state instead of labels

Removing any label from a PR fired the unlabeled trigger, creating a workflow run whose jobs were all skipped by the label guard. Such a run is the newest one on the PR, and because a job-level if skips before matrix expansion its check names are the raw templates (gcc-${{ matrix.gcc }}), which never occur in a real run and are therefore never superseded. The result is a PR status list where phantom skipped checks sit on top of, and obscure, the genuine CI results.

Auto-PR already opens conflicted backports as drafts, so draft state carries exactly the same information as the needs-manual-merge label. Gate on it and trigger on ready_for_review, which as a real event also recomputes the merge ref, letting a backport pick up a base branch that has moved on. The -noop concurrency group existed only to keep label-triggered runs from cancelling real ones, and is no longer needed.

ci(autopr): drive the backport cascade with a need-backport label

The bugfix label conflated two independent questions: what kind of change this is, and whether it should keep propagating down the release branches. need-backport now answers the second one. A hand-authored PR labelled bugfix is promoted to need-backport once, and from then on the cascade reads need-backport alone, so dropping that label from a backport PR stops the chain at that hop without touching bugfix. Promotion is deliberately allowed to throw: silently losing a backport is worse than a red run.

Labels are inherited from the source PR rather than hardcoding bugfix, so a bugfix or feature PR stays traceable along the whole chain. needs-manual-merge is excluded from inheritance because it records one hop’s cherry-pick outcome, not a property of the change.

Backport PRs opened before this change carry bugfix only; they need need-backport added by hand before merging, or their cascade stops there.

PhotonLibOS

PhotonlibOS.github.io

What’s New

Photon’s RPC framework has been published in PPoPP’26 (The ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming), and the full paper can be accessed at ACM Digital Library.
Photon has been included in awesome-cpp.
Version 0.9 has been released in April 2025.
We present an article to illustrate the theory of Photon’s coroutine. Stackful Coroutine Made Fast
Version 0.8 has been released in August 2024
Feb 2024，中文文档在官网上线了
Since 0.7, Photon will use release branches to enhance the reliability of software delivery. Bugfix will be merged into a stable release at first, then to higher release versions, and finally main.
Since version 0.6, Photon can run with a userspace TCP/IP stack on top of DPDK. En / 中文.
How to transform RocksDB from multi-threads to coroutines by only 200 lines of code? En / 中文.

Click to show more history...

Version 0.5 is released. Except for various performance improvements, including spinlock, context switch, and new run queue for coroutine scheduling, we have re-implemented the HTTP module so that there is no boost dependency anymore.
Version 0.4 has come, bringing us these three major features:
1. Support coroutine local variables. Similar to the C++11 thread_local keyword. See doc.
2. Support running on macOS platform, both Intel x86_64 and Apple M1 included.
3. Support LLVM Clang/Apple Clang/GCC compilers.
Photon 0.3 was released on 2 Sep 2022. Except for bug fixes and improvements, a new photon_std namespace is added. Developers can search for std::thread, std::mutex in their own projects, and replace them all into the equivalents of photon_std::<xxx>. It’s a quick way to transform thread-based programs to coroutine-based ones.
Photon 0.2 was released on 28 Jul 2022. This release was mainly focused on network socket, security context and multi-vcpu support. We re-worked the WorkPool so it’s more friendly now to write multi-vcpu programs.
Made the first tag on 27 Jul 2022. Fix the compatibility for ARM CPU. Throughly compared the TCP echo server performance with other libs.

Introduction

Photon is a C++ library designed to augment the operating system in terms of high-performance concurrent I/O programming. Photon is collected from Alibaba Cloud Storage team’s internal code base. It has been extensively tested and used in production, and is the same code they depend on in their daily lives.

Photon features a highly efficient user-space threading model, implemented as coroutines with multi-core CPU support, driven by a variety of asynchronous event engines such as epoll, io_uring, and kqueue, etc. These event engines are abstracted behind a lightweight, unified interface.

Built on this foundation, Photon provides a comprehensive set of high-level abstractions for networking and file I/O operations, leveraging both kernel-based system calls and high-performance user-space frameworks like DPDK and SPDK.

Furthermore, Photon includes entirely new, ground-up implementations of key distributed system components, including RPC, HTTP client and server, and Redis client, etc., delivering significantly higher performance and efficiency compared to existing solutions. The architecture of Photon is illustrated below:

Photon is well-suited for developing any I/O-intensive applications, including those involving disk I/O and/or network I/O.

Performance Photon can switch to a thread in just a few nanoseconds; this action corresponds to callback in a typical asynchronous framework. The cost of creating a new thread is primarily a simple malloc(), and the allocation can be pooled for even greater efficiency. Performance benchmarks on I/O workloads are available here.
Production Photon is the foundation of many production systems in (listing in alphabetical order) Alibaba Group, Ant Group, ByteDance, Xiaomi, XSKY, etc., and many open source projects in public domain.
- overlaybd, a sub-project of containerd, which is deployed at scale in Alibaba’s own infrastructure as well as the public cloud platform.
- OSSFSv2, a high-performance client for Alibaba Cloud’s object storage service (OSS) that provides a POSIX-compliant file system interface to the users.
- Connector for AI/ML, a high-performance storage driver for popular AI frameworks, such as Pythorch, safetensors, vllm, etc., supporting dataset reading, checkpointing, model loading.
- P2P Transport, a key component that addresses the scalability issue of large scale data serving, which is found in many scenarios like container image service, or AI model loading, etc.
- Caching services, such as OSS Accelerator, a multi-tenant distributed caching service for high-performance object access; or EFC cache, a client-side caching module for elastic file client (EFC).
- KTransformers, a flexible, Python-centric AI framework with advanced kernel optimizations and placement/parallelism strategies, designed with extensibility at its core. Photon is used to asynchronously load kvcache data from disk to memory, or vice versa.
- The coroutine engine in VLang
Agility Photon is designed to support a wide range of applications — and is already deployed in production across diverse environments. We’ve gone beyond mere feasibility, engineering it to be not only highly adaptable, but also intuitive, convenient, and fast to use. This is made possible through a set of well-defined, modular abstractions that decouple core logic from underlying system specifics, enabling both flexibility and performance.
Portability Photon supports multiple platforms, i.e. the combinations of {Linux, macOS} * {x86_64, ARM64} * {gcc, clang}.
Inclusion in awesome-cpp

Community

Join Slack: link

Join DingTalk group: 55690000272