How to determine the correct kernel source tag for CI/GitHub Actions automation?

[OrvilleQ]

Hi everyone,

I am currently trying to repurpose an old enterprise SD-WAN device (VeloCloud Edge 520) as a router by installing OPNsense. Unfortunately, VeloCloud made some non-standard hardware modifications to this device, so I have to patch and modify the kernel to get it working properly.

Since OPNsense releases updates roughly twice a month, I don't want to manually rebuild the kernel every time, nor do I want to be stuck on an outdated version. Therefore, I plan to set up a GitHub Action to automate the custom kernel build process whenever a new version is released.

However, I'm currently a bit confused about the relationship between OPNsense release versions and kernel versions.

For example, I see that OPNsense 26.1.2 was released on January 12th. However, I cannot find a 26.1.2 tag in the opnsense/src repository on GitHub—the latest tag I see is only 26.1.1. Additionally, I checked pkg.opnsense.org and didn't see a kernel package specifically released for 26.1.2.

So,

1. Does this mean that the 26.1.2 release did not bring any changes to the kernel compared to 26.1.1?

2. But I do noticed there are commits in opnsense/src between the 26.1.1 tag and the 26.1.2 release date. Then should I just ignore them?

3. If I upgrade from 26.1.1 (with custom kernel installed) to 26.1.2, do I not need to replace my custom 26.1.1 kernel or just reuse it?

4. But if I were to perform a fresh install of 26.1.2, should I simply install the kernel based on the 26.1.1 source tag?

5. Is there a specific documented workflow or release engineering process for OPNsense that I can reference? I would like to understand exactly how the versioning and tagging logic is handled between the core system and the kernel.

Thanks in advance.

[Maurice]

1. Correct. Not every OPNsense update includes a new kernel + base.
2. Yes. These commits will be in a future version (26.1.3 or later).
3. Updating from 26.1.1 to 26.1.2 will not modify the installed kernel + base, so nothing to do.
4. Correct.
5. If an update includes a new kernel + base, there will be a src tag with the same version as the core tag (which determines the version used in the UI, release notes etc.). If an update doesn't include a new kernel + base, there's simply no new src tag.

Cheers
Maurice