Fork the Repository

Build with Actions · Step 1

From this point on, things get much smoother.

Fork Steps

1. Find the Fork button next to the Star button on the project page and click it
2. Keep or rename the Repository name as you like
3. Uncheck "Copy the mainline branch only"
4. Click Create fork

Get the YML Template

# Clone your fork locally
git clone https://github.com/<your-username>/NonGKI_Kernel_Build_2nd.git
cd NonGKI_Kernel_Build_2nd

# Switch to the sample branch and copy the template
git switch sample
cp .github/workflows/build-sample.yml ~/

# Switch back to mainline
git switch mainline

# Move the template into the workflows directory
mv ~/build-sample.yml .github/workflows/

Alternatively, download build-sample.yml directly via its raw URL on GitHub.

YML File Naming Convention

If you plan to submit a PR, your file name must follow this pattern:

build-{brand}-{model}-{rom-abbrev}-{android-version}-{kernel-name (optional)}.yml

Example: build-xiaomi-polaris-los-a15.yml

ROM abbreviation rule: LineageOS → los, and so on for other ROMs.

The name Field Format

name: Build {Brand} {Model} ({Full ROM Name} {Android Version}) {Kernel Name (optional)}

Example: Build Xiaomi Mix2s (LineageOS A15)

The second name field (inside the job definition) does not need the Build prefix.

Creating a Separate Repository for SuSFS Secondary Patches

If you need to use a secondary patch file in the automated Action pipeline, it is recommended to manage it in a dedicated GitHub repository.

1. Click your avatar in the top-right corner of GitHub and go to Repositories
2. Click the green New button in the top-right corner
3. Enter a name in the Repository name* field, for example: NonGKI_Kernel_Patches
4. Click Create repository at the bottom-right to finish

After cloning it locally, organize patch files by device in subdirectories to make the path easy to reference in your YML configuration:

NonGKI_Kernel_Patches/
└── evox_mix2s_a15/
    └── susfs_fixed.patch