search

ataradov / edbg

Simple utility for programming MCUs and FPGAs though CMSIS-DAP protocol. Works on Linux, MAC and Windows.
BSD 3-Clause "New" or "Revised" License
283 stars 93 forks source link

Migrate to GitHub Actions? #101

Closed ooxi closed 3 years ago

ooxi commented 3 years ago

Unfortunately travis-ci.org will shut down in December. While Travis CI encourages moving to travis-ci.com, I do not recommend this move, since the open source build minutes are severely limited.

I therefore propose to migrate the CI to GitHub Actions. There are other alternatives like Circle CI, however I am most familiar with GitHub Actions.

Would moving to GitHub Actions be ok for you? I would propose a pull request.

ataradov commented 3 years ago

I already moved to travis-ci.com, but I don't really care what builds those binaries. GitHub Actions would work for me.

If there is a way to publish a GuHub release, it would be fine too instead of using Bintray.

ataradov commented 3 years ago

BTW, MAC OS build now fails with the following error:

$ make all
gcc -I/usr/local/include/hidapi -W -Wall -Wextra -O2 -std=gnu11 dap.c edbg.c target.c target_atmel_cm0p.c target_atmel_cm3.c target_atmel_cm4.c target_atmel_cm7.c target_atmel_cm4v2.c target_mchp_cm23.c target_st_stm32g0.c target_gd_gd32f4xx.c  dbg_mac.c -framework IOKit -framework Foundation -framework CoreFoundation /usr/local/lib/libhidapi.a -o edbg
Undefined symbols for architecture x86_64:
  "_NSAppKitVersionNumber", referenced from:
      _hid_init in libhidapi.a(hid.o)
ld: symbol(s) not found for architecture x86_64

I'll disable it for now, since I have not idea about any MAC specific stuff. And I don't care that much about apple to waste a lot of time investigating this.

ooxi commented 3 years ago

@ataradov unfortunately I'm not that familiar with mac os myself, but I'll try to fix it

ataradov commented 3 years ago

Don't waste a lot of time on that. MAC port is not great to begin with. It relied on hidapi library and that may have been broken. And I personally don't care to waste any resources on apple.

ooxi commented 3 years ago

Btw. the GitHub Actions port is almost done. However GitHub Releases does not work properly yet but I have hopes of fixing it

ooxi commented 3 years ago

@ataradov GitHub Releases is more complex than initially estimated :-( the reason for this is that you have to separately create a release and then attach binaries. Which is quite a hassle.

Would you be OK with staying with bintray for now and maybe migrate to GitHub Releases later?

ataradov commented 3 years ago

Sure, I'm fine with whatever.

ataradov commented 3 years ago

Bintray is going away May 1st. https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

ooxi commented 3 years ago

Aw man :-( I'm sure I can figure GitHub releases out :-)

ataradov commented 3 years ago

I'm considering another option. Just make a simple Python script that would just check the repo periodically. And run that on a dedicated server. Then serve the binaries from the same server. I have a server that can do this. It does not have a ton of bandwidth, but can probably support downloads for this.

ataradov commented 3 years ago

This would eliminate MAC builds, but MAC is such a PITA that I don't really care.

ooxi commented 3 years ago

That would be great for providing releases! I would still like to have CI for pull requests, but serving releases from your website would be even better, since you have full control and it's thus from a verified origin

ataradov commented 3 years ago

CI is moved to GitHub actions. Binaries would be published automatically later, once I figure out the best way to do that.