Automate builds with CD-CI or build server

filberg commented

2020-04-03 14:11:54 +02:00

(Migrated from github.com)

It would be nice to have a CD/CI infrastructure in place, to keep tracking the latest linux-libre upstream kernel, without having to manually launch new builds each time a new version is available.

I would be available for maintaining such an infrastructure, if the project is willing to take that path. Unfortunately, I'm totally ignorant in the field of CD/CI, build servers et similia; yet, I'm eager to learn if anybody provides me with startup tips..

It would be nice to have a CD/CI infrastructure in place, to keep tracking the latest linux-libre upstream kernel, without having to manually launch new builds each time a new version is available. I would be available for maintaining such an infrastructure, if the project is willing to take that path. Unfortunately, I'm totally ignorant in the field of CD/CI, build servers _et similia_; yet, I'm eager to learn if anybody provides me with startup tips..

ghost commented

2020-04-03 18:28:46 +02:00

(Migrated from github.com)

CI makes sense if there are multiple commits a day from several developers.
If you can set up an automated clone of the repo and just push a new image after changes that would be it. CD only makes sense if you have hardware to test the image on, qemu or similiar wont complain much i guess.

uptodate linux-libre integration can be done via git submodules - i may try that in my fork.

CI makes sense if there are multiple commits a day from several developers. If you can set up an automated clone of the repo and just push a new image after changes that would be it. CD only makes sense if you have hardware to test the image on, qemu or similiar wont complain much i guess. uptodate linux-libre integration can be done via git submodules - i may try that in my fork.

filberg commented

2020-04-03 18:59:03 +02:00

(Migrated from github.com)

Ok, got it.. thanks for clarifying!

I blatantly misjudged the scope and application of CD/CI, it seems..
Always good to learn, even by publicly putting myself to shame 😄

If you can set up an automated clone of the repo and just push a new image after changes that would be it

This is something I'm interested in, but I'd like the whole system to be tightly integrated with the official project release cycle; thus I'd like to discuss how I could put up such an infrastructure so that it's easily leveraged by PrawnOS as a project.

Ok, got it.. thanks for clarifying! I blatantly misjudged the scope and application of CD/CI, it seems.. Always good to learn, even by publicly putting myself to shame :smile: > If you can set up an automated clone of the repo and just push a new image after changes that would be it This is something I'm interested in, but I'd like the whole system to be tightly integrated with the official project release cycle; thus I'd like to discuss how I could put up such an infrastructure so that it's easily leveraged by PrawnOS as a project.

ghost commented

2020-04-03 19:10:42 +02:00

(Migrated from github.com)

Its not a shame, for projects like openwrt or an app the tools are way more complicated, just not really needed here. I have no idea about CI/CD either, but thats essentially what they do. 1 maintainer and 1 target in hardware is easily tested by just building it after a change.

A simple script to update the submodule, main tree and try to build an image every night would do the job.

Its not a shame, for projects like openwrt or an app the tools are way more complicated, just not really needed here. I have no idea about CI/CD either, but thats essentially what they do. 1 maintainer and 1 target in hardware is easily tested by just building it after a change. A simple script to update the submodule, main tree and try to build an image every night would do the job.

SolidEva commented

2020-04-04 01:10:54 +02:00

(Migrated from github.com)

EDIT: I am also new to CI/CD so some of my assumptions about it are likely wrong.

I have thought about doing this, but a few things have kept me from automating kernel updating and building.

I usually tweak the config options a bit when new kernel config options are added or moved. I would be hesitant to automate that process as sometimes the default is incorrect for this platform. Specifically I remember a time where they moved the ec driver in the kernel to a new config option, that was default "no".
Usually, when I want to test something I kick off a build right away and test manually as soon as it is complete. Having nightly builds wouldn't help there much.
Because I try and test before I push a commit, I also don't accept PRs until I have tested it first. So nightlies wouldn't be too helpful to anyone else either.

Automated testing of basic things like installation would be nice, but would be difficult to achieve as serial access isn't straightforward and neither is getting a new image on a device without human interaction. Maybe I can figure out a way to toggle on/off usb serial. I would also need to figure out getting the built image on a usb device or sd card, and then plugged into the system automatically.

So far, it has been easier to just build an image and manually test it. But that certainly doesn't scale well.
As interest in PrawnOS grows, I could definitely see adding a "development" branch that gets built automatically. Might make sense to add that soon....

EDIT: I am also new to CI/CD so some of my assumptions about it are likely wrong. I have thought about doing this, but a few things have kept me from automating kernel updating and building. 1) I usually tweak the config options a bit when new kernel config options are added or moved. I would be hesitant to automate that process as sometimes the default is incorrect for this platform. Specifically I remember a time where they moved the ec driver in the kernel to a new config option, that was default "no". 2) Usually, when I want to test something I kick off a build right away and test manually as soon as it is complete. Having nightly builds wouldn't help there much. 3) Because I try and test before I push a commit, I also don't accept PRs until I have tested it first. So nightlies wouldn't be too helpful to anyone else either. Automated testing of basic things like installation would be nice, but would be difficult to achieve as serial access isn't straightforward and neither is getting a new image on a device without human interaction. Maybe I can figure out a way to toggle on/off usb serial. I would also need to figure out getting the built image on a usb device or sd card, and then plugged into the system automatically. So far, it has been easier to just build an image and manually test it. But that certainly doesn't scale well. As interest in PrawnOS grows, I could definitely see adding a "development" branch that gets built automatically. Might make sense to add that soon....

ghost commented

2020-05-19 01:28:03 +02:00

(Migrated from github.com)

1. Specifically I remember a time where they moved the ec driver in the kernel to a new config option, that was default "no".

lol

> 1. Specifically I remember a time where they moved the ec driver in the kernel to a new config option, that was default "no". lol

austin987 commented

2020-05-20 08:36:05 +02:00

(Migrated from github.com)

We now have automated builds with github actions, IMO this can be closed. I opened #165 to keep track of automated testing with qemu.

👍 1

Rows
Columns

Automate builds with CD-CI or build server #150