Hi Tatu, I think this is a good idea. Please note that GitHub also limits the number of GitHub Actions minutes per month, depending on which plan you have. I can see that you are on the Pro plan so you should have 3000 minutes per month (the default for the free plan is 2000) [1]. There are other limits regarding the number of concurrent jobs etc. [2]. The limits should be more than enough for almost all open source projects -- I just wanted to mention them in case you have different requirements.
By the way, I'm using GitHub Actions for all my open source projects (including bson4jackson). I was an early adopter and have quite some experience with it. If you need help, just let me know. Cheers, Michel [1] https://docs.github.com/en/get-started/learning-about-github/githubs-products [2] https://docs.github.com/en/actions/reference/usage-limits-billing-and-administration > On 23. Jun 2021, at 22:58, Tatu Saloranta <t...@fasterxml.com> wrote: > > Looks like Travis-CI transition from .org to .com is now hitting us; > no CI build has succeeded for the past 15 days. While I did change > settings which should give us some free builds per month, I don't > think those 10,000 credits are enough for all Jackson components (not > even sure it'd cover jackson-databind). > While I understand that the business side of this may be necessary for > Travis the company, it means that either Jackson project would need to > pay up, or, perhaps, we should consider moving to something like > Github Actions. > As G.A seems to be picking momentum, that seems like a reasonable > idea, but it is a new system for me and I would need some help. > > On migration: Jackson builds are rather simple, and aside from > optimization aspects (if there are ways to cache Maven deps, f.ex), > the only advanced part in Travis was the automatic publishing of > SNAPSHOT versions. And that is/was tricky just due to auth tokens. So > perhaps migration would not be horribly complicated. > > Also... this might make it easier to consider dependency builds: so > that, for example, build of `jackson-core` (of certain branch) could > trigger cascading build of its dependencies (`jackson-databind`, most > modules). > Even if this was not fully automatic -- that is, we'd need to do some > static configuration -- it could be useful in exposing issues that > currently are not immediately apparent. > Or, possibly we could simply force daily/weekly rebuilds of a set of > repos (base modules, 3 dataformat repos) which should also catch > cross-version compatibility issues. > > -+ Tatu +- > > -- > You received this message because you are subscribed to the Google Groups > "jackson-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to jackson-dev+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jackson-dev/CAL4a10jimXsSZxHC80bwOEfnZjFS8PN6OMWwnRXvdpekehqaRw%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "jackson-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to jackson-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jackson-dev/4BB4B52B-1B89-4B51-B2E1-877EC044F532%40googlemail.com.
