rroche
July 18, 2023, 4:01pm
1
The maintainers meeting is a meeting for the developer team to coordinate on pressing issues and to plan the development of the PX4 Autopilot project, the community is welcome to join and listen, but won’t be able to speak unless specific access is granted ahead of time.
/****************************************************************************
*
* Copyright (c) 2018-2021 PX4 Development Team. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in
* the documentation and/or other materials provided with the
* distribution.
* 3. Neither the name PX4 nor the names of its contributors may be
* used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
* "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
show original
For VIO use case, wanted to use that module but it is tailored to PPK use cases, with requirements tangled with GPS data
PX4:release/1.14 ← junwoo091400:release/FAKE_RELEASE_JUNWOO_TEST
opened 07:23PM - 19 Jul 23 UTC
## About
I noticed that past releases' metadata generation scripts runs (https:… //github.com/PX4/PX4-Autopilot/actions/workflows/deploy_all.yml?query=branch%3Arelease%2F1.13) were uploading metadata to Firmware/master directory of the S3 bucket (e.g. http://px4-travis.s3.amazonaws.com/Firmware/master/px4_fmu-v5_default/actuators.json).
Such example can be found here: https://github.com/PX4/PX4-Autopilot/actions/runs/5544330196/jobs/10121657718#step:7:14
Where the 1.13 release branch's metadata is getting uploaded to master folder in the S3
What should happen instead, is the `get_git_tag_or_branch_version.sh` should set the `version` environment variable o a correct release version (e.g. "release-1.13") based off of the branch naming:
https://github.com/PX4/PX4-Autopilot/blob/a37e3e7b060fbc56e8b0459b22813aee6d8a0a62/.github/workflows/deploy_all.yml#L42
So, I have created this PR with branch naming satisfying the "release/*" syntax, to check output of the environment variables and check why the `env.version` (Value of `version` in the `$GITHUB_ENV`)
Will need to coordinate with beat too to figure out how to handle metadata in general
July 25, 2023
Meeting Link
Agenda
Meeting Notes