simple github actions workflow for continous integration

[gretel]

example run - it's not finishing cause of missing files:

 head: cannot open 'hw/hank/noctigon-k9.3/nofet/model' for reading: No such file or directory

serves as an example why continous integration can be useful 😸 please see a finished run of a similar workflow.

guess lines in your .gitignore did keep some files from getting commited:

*.[0123456789]
*.[0123456789][0123456789]

regards

[gretel]

missing files resolved

[ToyKeeper]

Seems pretty useful. Looks like it needs some changes to use the right branch name though, and ideally should cache dependencies instead of downloading each time. So I'm looking up how to do that... I'll probably push a few commits here to test what works.

[gretel]

Seems pretty useful. Looks like it needs some changes to use the right branch name though, and ideally should cache dependencies instead of downloading each time. So I'm looking up how to do that... I'll probably push a few commits here to test what works.

from my experience caching usually introduces more issues than it solves, including saving energy. besides, i'd suggest to have that in a separate PR eventually which i can provide at a later point in time.

how would you like the triggers to be adjusted?

[ToyKeeper]

After a bit of poking and prodding and experimenting and test runs, it seems ready to go. It caches the DFPs, to avoid downloading excessively from Atmel, but I didn't try to cache anything else. I assume github has their own apt repositories, so no point in trying to cache those.

I'm not entirely sure it needs to save the .hex files, but I don't really see a reason not to, so I left it in.

[gretel]

After a bit of poking and prodding and experimenting and test runs, it seems ready to go. It caches the DFPs, to avoid downloading excessively from Atmel, but I didn't try to cache anything else. I assume github has their own apt repositories, so no point in trying to cache those.

glad to hear!

if you intend to apply the workflow to most branches caching the download makes sense, sure. luckily the apt infra has autoselection of cdn-backed servers so no issues here.

I'm not entirely sure it needs to save the .hex files, but I don't really see a reason not to, so I left it in.

• sort of a prequel to provide binary releases on tagged commits 🥳
• "nightly" releases for people to test (and use) 🌃
• archival.. documentation of the acutal result 📚
• some people go crazy for "reproducible build" setups these days, like me 😆

please adjust the retention time in the repo's settings if you feel the default is not right.

is there anything else in this context i can help with?