-
Notifications
You must be signed in to change notification settings - Fork 55
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
Add the ability to flash nightly build firmware from the CI/CD artifacts #102
Comments
Nightlies should definitely have a separate place, maybe their own dropdown activated by a checkbox or similar. How is the current structure of the artifacts? Is it enough to only offer the latest build? If so then I would suggest the following structure:
|
Currently, nightly structure only exists in action's artifacts. It's a separate zip file but one only have bin for config tool and another only have hex for configurator. I can push it to another separate repo's release if you want. |
In order to properly integrate this, I would need to have access to the hex files seperately - so one zip is not enough. If you create new releases each day in a repo, we still have the problem that we can not access the latest just by "latest" tag, so more logic is required to fetch the hex files. I think, having the assets available as separate files (in a seperate repo) is a good idea, I am just not sure if it is worth the hassle to integrate it into the configurator. |
Putting them directly in repo instead of repo's releases might be difficult, I haven't seen any real example that push the artifacts into the repo or any action can do this. But the release tag can be modified automatically. A real example that implement nightly build in configurator is the betaflight-configurator, but I haven't look into its mechanism about accessing/fetching those nightly's tags. Well I'm also not sure whether it worth the effort, but TBH I really like the betaflight configurator can allow users just flash nightly builds instead of load them manually. Sometimes we can really found a bug in it. |
Sorry, maybe that was confusing - I meant the repo's releases - anything else would not make sense. And yeah, if the tag could always be updated to latest, that would be OK. |
Do you have any idea how betaflight configurator fetching nightly builds? @asizon |
The point is, that we can't really compare it to BF, since we also need up to date EEPROM Layouts - otherwise we can flash a dev version, but have no way of actually adjusting the settings. So the whole thing is a bit tricky. Just flashing is no big deal, as long as I can access the files separately in some way. I can also just grab the latest 10 releases from a repo and render them as "development" versions. The tags could then simply be the date when the firmware was built. So my suggestion would be to set up a repo that only holds the releases and the matching assets. The structure of the assets should be exactly the same as in the regular repo. For AM32 that would be:
The URL for the nightlies would then be:
Then I could easily fetch a list of latest versions via GH API and build the URL for the matching FW. As you see it is important not to have a version in the pattern, so I can reliably re-use the same URL. |
oh, no version huh? It won't be that tough |
Cool. Yes - because if it had a version I would need to each time add a new URL. Without version I set it up one time and it will work for ever ;-) |
That will somehow ease the testing workflow. Authors only need to tell testers which build number to flash, no need for loading local hex files.
I can see there is now only AM32 has a CI/CD system, but I think in the future bluejay will also have one.
I can change the AM32 CI/CD to make the URLs for artifacts can be easily grabbed by configurator, just tell me the format/style you prefer.
The text was updated successfully, but these errors were encountered: