Skip to content
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

Open
DusKing1 opened this issue Apr 14, 2021 · 9 comments
Open

Comments

@DusKing1
Copy link
Contributor

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.

@stylesuxx
Copy link
Owner

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:

/releases/download/nightly/{0}_latest.hex

@DusKing1
Copy link
Contributor Author

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.

@stylesuxx
Copy link
Owner

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.

@DusKing1
Copy link
Contributor Author

DusKing1 commented Apr 16, 2021

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.

@stylesuxx
Copy link
Owner

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.

@DusKing1
Copy link
Contributor Author

Do you have any idea how betaflight configurator fetching nightly builds? @asizon

@stylesuxx
Copy link
Owner

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:

https://github.com/AlkaMotors/AM32-MultiRotor-ESC-firmware/releases/download/v1.65/{0}_1.65.hex

The URL for the nightlies would then be:

https://github.com/$USER/$REPO/releases/download/{TAG}/{0}.hex

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.

@DusKing1
Copy link
Contributor Author

oh, no version huh? It won't be that tough

@stylesuxx
Copy link
Owner

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 ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants