-
Notifications
You must be signed in to change notification settings - Fork 93
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
CI/CD basic implementation based on GitHub Actions #167
Conversation
…t extractable due to detached git repo state on GH build server
…chain which has strange issue with LTO stage (https://forum.chibios.org/viewtopic.php?t=5830)
…chain which has strange issue with LTO stage (https://forum.chibios.org/viewtopic.php?t=5830) using container
…e for this use case (actions/checkout#1590)
Ok, it seems that after all with the power of bash & git commands we can get all needed meta information at the time of building on github to embed version string. The question remains what string should be put into |
We must just build it like it was done on computer it create
In my case I'm using https://github.com/hydrabus/hydrafw of course in your case with your fork you will have different commit ...
At the end we shall find in the bin & dfu |
Ookay, some status update.
And here is the content of
Are these appropriate results? Just asking for confirmation before cleaning up all those |
Hello. Sorry to bother, but I'm just giving a friendly reminder of the most recent update since I'm very curious what you think. So, could you, please, just give me the feedback about the current patch-set for this pull-request. Although I understand that we all may be very busy sometimes so take your time, of course, so I'm not rushing, but just giving an update. Thank you. |
All seems good for me |
Looks good to me. @ia Thank you for the contribution ! |
Thanks for your contribution |
I have created a new issue #168 as the build has failed (after merge) |
…ore explicitly regardless build status (PR,merge,etc.) // hopefully fix for hydrabus#167
TL;DR: utilize GitHub capabilities to make builds on every commit and on every pull-request.
Hello. I'm a bit surprised that this haven't been done yet. So I decided to take some liberty to help with that. There may be a lot of room for improvements in the future but this is work-able proof-of-concept which can be merged & adopted as is currently in my humble opinion. However, to fully integrate
push.yml
intohydrafw
github project, admins may need to set some additional settings somewhere in Settings of the project using GitHub web interface manually.The benefits are:
dfu-util
, always be able to get the latest fresh build from main branch;Partially this overlaps with #132 and I can't promise anything but every time I have some free time I try to keep contributing around these CI/CD improvements as well.
Now, to technical details so everyone who is interested & curious could be on the same page. Basically,
push.yml
here is the most minimal declarative file which tells GitHub to start Ubuntu22.04
VM, then to start Debianoldstable
container inside, install toolchain packages, buildhydrafw.dfu
and upload it ashydrafw.dfu
artifact. The live "demo" can be seen in my forked repo here:hydrafw.zip
Now, why such "matreshka" with VMs/containers, you may ask. Well, GitHub doesn't have Debian
oldstable
to run it directly, but we can start it from VM which is available on GitHub. After tries & errors Debianoldstable
has been picked as [so far] the most suitable one, since:git
with fresh enough version to supportactions/checkout@v4
(it needsgit
> 2.17)GCC
toolchain where LTO forChibiOS
doesn't have a strange issue (sample log from one of my builds)If you have any other questions, just let me know.
Oh, and that tiny update for
python
script comes from specific behavior of GitHub actions: on every checkout before build, GitHub infrastructure doesn't make full validgit checkout
but downloads source tree in detached state so getting meta information about repo and its status (tag, revision, sha, etc.) may be tricky because I saw that with other GitHub projects so for a while we set revision as0.0
for GitHub builds (which is default value) but it's even good in its own way because by that it will be the indicator that it is the latest upstream mainline build but not a stable release.