Channels / #fineract / 2026-01-22

#fineract 2026-01-22

reply Thu 15:25Horlugingin Ayoade
dropped a comment .
Thu 17:21Soham Pirale
@Soham Pirale has joined the channel
reply Thu 19:07Adam Monsen (meonkeys)
LGTM (especially with the space at the end of the regex)
reply Thu 19:07Adam Monsen (meonkeys)
Tangent/idealism: In general I'd rather see more build/test/check independence/portability to avoid vendor lock-in (vendor in this case is GitHub). Doesn't really apply in this case (since this is specific to GitHub PRs), but there are better examples in `~/.github/workflows` of GitHub Actions that could be moved into scripts that would work locally/anywhere (e.g. with Docker) and simplified to just run those scripts.
reply Thu 19:50Krishna Mewara (DeathGun44)
Thanks for the review, Adam! I've updated the regex with the space.

​That Jira check is a cool idea for the future. My only worry would be if the Apache Jira server is ever slow or down, it might make the CI flaky even if the code is fine. But I can definitely see the value in catching non-existent tickets!
👍 1 🙌 1
reply Thu 23:21James Dailey
That ticket ref is important for traceability and generating release notes. Is there an alternative way to trigger that, once a day maybe?
reply Fri 03:06Krishna Mewara (DeathGun44)
That makes perfect sense. Moving the Jira ticket validation to a nightly scheduled job seems like the ideal middle ground.

It would act as an audit log—ensuring we catch invalid references for the release notes and traceability—but without the risk of a Jira outage or network hiccup blocking the daily PR queue.

If that sounds like the right approach to you both, I'd be happy to open a separate issue and setup a cron workflow to handle that.
reply Fri 16:23Adam Monsen (meonkeys)
No, I don't like that. An async job to check this seems overly complex. It would need state saved somewhere to figure out which PRs/issues to check.
reply Fri 16:23Adam Monsen (meonkeys)
We're likely discussing a low priority unlikely edge case here: a specific typo in a PR title where the referenced JIRA issue doesn't exist. And there's already a passive but consistent visual indicator in the other direction: an auto-created link in the JIRA ticket to the PR.

Anyway, say the error were made and not detected until 6mo later -- that makes no functional difference for a release, and the wiki page with release notes can be easily fixed after the fact.
reply Fri 16:27Adam Monsen (meonkeys)
but, again, my vote is to just move on, leave this as-is for now. There's plenty more and higher-priority tech debt to pay off and build logic to improve
reply Fri 17:08Krishna Mewara (DeathGun44)
Fair point, Adam. leaving it as-is for now.
👍 2