Hi Aman,

Thanks for the correction — you're right, public forks have unlimited
Actions minutes. The billing concern I mentioned doesn't apply here.

That said, the core point I wanted to make is more about workflow
efficiency than cost:

   -

   Running the full CI matrix (~37 jobs, up to 60 min each) on every push
   is slow for iterative development
   -

   The workflows don't use concurrency groups, so pushing again doesn't
   cancel in-progress runs — they pile up and need manual cancellation
   -

   Running targeted tests locally (./gradlew test, spotlessCheck, specific
   integration tests) gives much faster feedback before pushing

Essentially: local testing first for fast iteration, CI as the final
confirmation.

On Wed, 18 Feb 2026 at 19:12, Aman Mittal <[email protected]>
wrote:

> Hi Krishna,
>
> If you are running the GitHub action on public fork, it doesnt bill
> towards your quota.
>
> On Wed, 18 Feb, 2026, 7:07 pm KRISHNA MEWARA, <[email protected]>
> wrote:
>
>> Building on Aman's point about testing on forks—I'd like to share a
>> practical challenge I ran into, especially on free GitHub accounts.
>>
>> Fineract's CI pipeline is massive: each push triggers ~37 parallel jobs.
>> On free accounts, this eats through your *2,000 minutes/month quota*
>> incredibly fast. Since the workflows don’t currently use *concurrency
>> groups*, pushing a quick fix doesn't cancel the previous run—it just
>> doubles the burn.
>>
>> Here’s the workflow I’ve found saves time and minutes:
>>
>>    1.
>>
>>    *Run unit tests locally first:* > ./gradlew test -x
>>    :twofactor-tests:test -x :oauth2-tests:test -x :integration-tests:test
>>    (Runs ~1,000 tests with no external services).
>>    2.
>>
>>    *Run code quality checks locally:* > ./gradlew spotlessApply
>>    spotlessCheck checkstyleMain checkstyleTest (Catches formatting/style
>>    issues *before* the CI fails on them).
>>    3.
>>
>>    *Run targeted integration tests:* Only for the area you changed. The
>>    Cargo container plugin handles the Fineract startup automatically.
>>    4.
>>
>>    *Push only when confident:* Use the full CI matrix as a final
>>    confirmation rather than a debugging tool.
>>
>> This gives you faster feedback and saves the heavy-lifting (multi-DB
>> matrix, E2E, messaging smoke tests) for the final push.
>>
>> Regards,
>> Krishna
>>
>> On Wed, 18 Feb 2026 at 18:56, Arnav Patil <[email protected]> wrote:
>>
>>> Hi Adam,
>>>
>>> Thank you for the guidance
>>>
>>> I’ve already made a couple of contributions to Fineract, and I’m looking
>>> to gradually take up more impactful issues. I plan to continue working on
>>> unresolved bug tickets and possibly address some compilation warnings to
>>> improve maintainability.
>>>
>>> I’m also exploring some loan-related issues to better understand the
>>> accrual and transaction processing flow, and I’ll make sure to discuss any
>>> larger feature ideas on the DEV list before starting.
>>>
>>> Thanks again for the direction.
>>>
>>> Regards,
>>> Arnav
>>>
>>> On Wed, Feb 18, 2026 at 6:48 PM Aman Mittal <
>>> [email protected]> wrote:
>>>
>>>> Adding few bits regarding code refractoring.
>>>>
>>>>
>>>> You can you 2 tools that are easily available in Intelij Idea
>>>>
>>>> 1. Idea's inbuilt code analysis.
>>>> 2. Another is SonarLint
>>>>
>>>>
>>>> Caveats included
>>>>
>>>> There are some suggestions that may not follow fineract coding
>>>> conventions. Or may cause regressions
>>>>
>>>> To detect them early you can run GitHub Actions on your local fork. So
>>>> that you can double sure that your not breaking anything.
>>>>
>>>> Regards
>>>> Aman Mittal
>>>>
>>>>
>>>>
>>>> On Wed, 18 Feb, 2026, 6:38 pm Aira Jena, <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Adam,
>>>>> Thanks for putting this together — this is very helpful, especially
>>>>> for newcomers like me who are trying to understand where to start.
>>>>> I particularly like the emphasis on bug fixes and reducing compilation
>>>>> warnings. Those types of improvements may look small individually, but 
>>>>> they
>>>>> significantly improve long-term maintainability and overall code health.
>>>>> Thanks again for sharing this direction.
>>>>> Best,
>>>>> Aira
>>>>>
>>>>>
>>>>> On 2026/02/18 12:58:06 Ádám Sághy wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I wanted to share some thoughts on what newcomers could work on.
>>>>> >
>>>>> > This isn’t a final list, just something that came to mind while I
>>>>> was thinking about it:
>>>>> >
>>>>> > Every contribution that enhances the codebase’s safety,
>>>>> effectiveness, or readability is valuable! :)
>>>>> >
>>>>> > Considering your availability and willingness to contribute, there
>>>>> are several areas where improvements are needed:
>>>>> >
>>>>> > Bug tickets
>>>>> >
>>>>> https://issues.apache.org/jira/browse/FINERACT-2492?filter=-1&jql=project%20%3D%20%22Apache%20Fineract%22%20%20AND%20type%20%3D%20Bug%20%20%20AND%20resolution%20%3D%20Unresolved%20order%20by%20created%20DESC
>>>>> >
>>>>> > Code maintainability / readability
>>>>> > We have a significant number of compilation warnings due to various
>>>>> reasons. I believe at least half of these warnings could be easily fixed.
>>>>> As we work on resolving these warnings, the codebase could become safer 
>>>>> and
>>>>> easier to maintain.
>>>>> >
>>>>> > All the rest of the stories
>>>>> >
>>>>> https://issues.apache.org/jira/browse/FINERACT-2494?filter=-1&jql=project%20%3D%20%22Apache%20Fineract%22%20%20AND%20resolution%20%3D%20Unresolved%20order%20by%20created%20DESC
>>>>> >
>>>>> > All the rest of the stories that are considered beginner friendly
>>>>> >
>>>>> https://issues.apache.org/jira/browse/FINERACT-2489?filter=-1&jql=project%20%3D%20%22Apache%20Fineract%22%20and%20labels%20IN%20(beginner-friendly%2C%20beginner%2C%20begineer%2C%20beginners%2C%20Beginner)%20%20AND%20resolution%20%3D%20Unresolved%20order%20by%20created%20DESC
>>>>> >
>>>>> >
>>>>> > Hopefully, this gives you some ideas!
>>>>> >
>>>>> > P.S.: Before you pick up a story that describes a new feature to be
>>>>> introduced, please send an email to the Fineract DEV email list to discuss
>>>>> whether it’s something we really want to include in Fineract.
>>>>> >
>>>>> > Regards,
>>>>> > Adam
>>>>> >
>>>>>
>>>>

Reply via email to