New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added support for Unified Target configurations with manufacturer_id in the name. #1692
Merged
mikeller
merged 1 commit into
betaflight:master
from
mikeller:add_manufacturer_id_support
Sep 28, 2019
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that needed? for a unified target I thought it was
betaflight-configurator/src/js/tabs/firmware_flasher.js
Lines 550 to 558 in 074bb46
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something that yields the available versions is needed.
The current way of using the non-unified .hex for this is not viable, as one goal of this whole exercise is to stop building / releasing them as soon as the Unified Target configurations are confirmed working for users, so the available versions for the non-unified targets will stop for some 4.1.x.
To get the actually used Unified Target .hex from the Unified Target config requires loading the file. If done when generating the list this will trigger GitHub's API request limiting (and be inefficient). If done when selecting a Unified Target configuration will introduce a delay and still trigger the request limit if a user is 'browsing'. So this is a pragmatic solution that will work for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Grabbing the individual config files isn't doing API calls. So I didn't worry about how many requests I do.
We're doing an API call to get the contents of
configs/default
(list of files) and another one for the releases. In the API call for releases, we get the last 30 releases, which is chock full of data.If you did a release with only unified targets, users would get the proper versions, its just that the (Legacy) option wouldn't include a latest version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But we get them on a per target basis. And if we use a target that has been replaced by a Unified Target configuration and isn't released any more to populate the Unified Target configuration's releases, there won't be any releases showing for after we've pulled the non-unified target from release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you download the releases, and remove the 4.1.0 RC builds for one target it looks like this:
This PR
Master
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, that is what I am going for - the aim is to phase out the non-unified targets in releases going forward (i.e. only Unified Targets and 'exotic' non-unified targets should be included in later 4.1.x releases).
For now, having access to the legacy targets provides a fallback for users if there are problems with Unified Targets, but in a future release we'll probably want to merge them into the 'normal' target selection, and give users non-unified targets for releases before 4.1.0-RC1, and Unified Targets after.
At this point we should also look into switching to using releases for the actual Unified Target .hex for every target - right now I am just not sure how best to do this. Speculatively loading all 140 (for now) Unified Target configurations seems to be a non-ideal way. Maybe we can generate a file containing a list of all Unified Target configurations with their required Unified Target .hex as part of the CI process in the
unified-targets
repository?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generating a file sounds good, if we do it as part of the CI process, where does it go? Oh we have options for that. My vote is github pages https://docs.travis-ci.com/user/deployment/pages/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking of a future CI process that would push any changes to master to something that is more suited as a content delivery network as well.
But even without this, or having CI modify the repository in any form, adding a script that re-generates the index file, requiring target maintainers to update the index file (by script or manually) as part of every pull request, and using CI to fail pull requests that fail to do so should work just fine as a first incarnation.