Ramon Roche 5389f75577 ci(container): add build_ref input to allow dispatch against arbitrary refs
The current workflow_dispatch path builds whatever HEAD of the dispatch ref
is, labels the resulting image with px4_version, and publishes. That's
fine for rebuilding current state but it cannot rebuild the exact commit
a release tag points to, because the dispatch loads the workflow file
from one ref and implicitly checks out the same ref for the build.

This matters for release recovery. When the v1.17.0-rc2 tag push failed
to publish containers back on 2026-03-13 (the v1 GHA cache protocol
removal in RunsOn v2.12.0), the tag was not re-pushed, so the only way
to publish rc2 containers now is via workflow_dispatch. Without this
change, a dispatch against release/1.17 builds release/1.17 HEAD and
labels it v1.17.0-rc2, which produces a container whose contents do not
match the rc2 tag's actual code. That is not a faithful recovery.

Add a build_ref input that controls only the checkout ref, defaulting
to empty which falls back to github.ref (preserving current behavior
for both push events and dispatches that omit the input). With this,
a release recovery looks like:

  gh workflow run dev_container.yml --repo PX4/PX4-Autopilot \
    --ref release/1.17 \
    -f px4_version=v1.17.0-rc2 \
    -f build_ref=v1.17.0-rc2 \
    -f deploy_to_registry=true

The workflow loads from release/1.17 HEAD (which has the cache fix
from 39b0568 and the hardening from d74db56a), but the build uses
Tools/setup/Dockerfile from the rc2 tag. The published image has
rc2 contents under the rc2 label, as if the original tag push had
worked.

All three actions/checkout steps (setup, build, deploy) take the same
ref expression so every job sees a consistent workspace. Non-dispatch
events (push, PR) evaluate github.event.inputs.build_ref to empty and
fall back to github.ref exactly as before.

Signed-off-by: Ramon Roche <mrpollo@gmail.com>
(cherry picked from commit e4d46f20f439094862eedd7e21c5abeefb1721f1)
2026-04-07 18:22:39 -06:00
2025-10-14 19:14:41 +02:00
2022-07-20 01:14:04 -04:00
2017-07-30 19:18:49 +02:00
2017-01-02 10:14:41 +01:00
2025-08-21 16:46:06 +02:00
2023-01-21 12:57:27 -05:00
2025-10-14 19:14:41 +02:00
2025-02-25 21:16:54 -05:00
2023-11-06 09:32:16 +01:00

PX4 Drone Autopilot

Releases DOI

Build Targets SITL Tests

Discord Shield

This repository holds the PX4 flight control solution for drones, with the main applications located in the src/modules directory. It also contains the PX4 Drone Middleware Platform, which provides drivers and middleware to run drones.

PX4 is highly portable, OS-independent and supports Linux, NuttX and MacOS out of the box.

Releases

Release notes and supporting information for PX4 releases can be found on the Developer Guide.

Building a PX4 based drone, rover, boat or robot

The PX4 User Guide explains how to assemble supported vehicles and fly drones with PX4. See the forum and chat if you need help!

Changing Code and Contributing

This Developer Guide is for software developers who want to modify the flight stack and middleware (e.g. to add new flight modes), hardware integrators who want to support new flight controller boards and peripherals, and anyone who wants to get PX4 working on a new (unsupported) airframe/vehicle.

Developers should read the Guide for Contributions. See the forum and chat if you need help!

Weekly Dev Call

The PX4 Dev Team syncs up on a weekly dev call.

Note

The dev call is open to all interested developers (not just the core dev team). This is a great opportunity to meet the team and contribute to the ongoing development of the platform. It includes a QA session for newcomers. All regular calls are listed in the Dronecode calendar.

Maintenance Team

See the latest list of maintainers on MAINTAINERS file at the root of the project.

For the latest stats on contributors please see the latest stats for the Dronecode ecosystem in our project dashboard under LFX Insights. For information on how to update your profile and affiliations please see the following support link on how to Complete Your LFX Profile. Dronecode publishes a yearly snapshot of contributions and achievements on its website under the Reports section.

Supported Hardware

For the most up to date information, please visit PX4 User Guide > Autopilot Hardware.

Project Governance

The PX4 Autopilot project including all of its trademarks is hosted under Dronecode, part of the Linux Foundation.

Dronecode Logo

 
Description
a mirror of official PX4-Autopilot
Readme BSD-3-Clause 587 MiB
Languages
C++ 51.2%
C 38.5%
CMake 4.7%
Python 3.9%
Shell 1.3%
Other 0.1%