Hello, this a begginers ticket anyone can take it, please use the jira for commenting the solution https://issues.apache.org/jira/browse/FINERACT-2447
Channels / #fineract / 2026-01-22
#fineract 2026-01-22
dropped a comment .
Thu 17:21Soham Pirale
@Soham Pirale has joined the channel
Thu 18:31Victor Romero
Hello Apache Fineract*®* channel, could you take a look at FINERACT-2158: Add workflow to enforce PR title convention https://github.com/apache/fineract/pull/5361 and submit your feedback please.
👀 1
LGTM (especially with the space at the end of the regex)
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.
Future improvement idea: ensure the referenced JIRA ticket exists, e.g.
```ISSUE_ID=2158
HTTP_CODE=$(curl -I -s -o /dev/null --write-out "%{http_code}" https://issues.apache.org/jira/browse/FINERACT-$ISSUE_ID)
[[ $HTTP_CODE -eq 200 ]]```
```ISSUE_ID=2158
HTTP_CODE=$(curl -I -s -o /dev/null --write-out "%{http_code}" https://issues.apache.org/jira/browse/FINERACT-$ISSUE_ID)
[[ $HTTP_CODE -eq 200 ]]```
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!
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
That ticket ref is important for traceability and generating release notes. Is there an alternative way to trigger that, once a day maybe?
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.
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.
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.
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.
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.
another approach would be to do the JIRA check also in `.github/workflows/pr-title-check.yml`, but don't fail the action if the check fails (if JIRA is down or if the referenced ticket doesn't exist), rather, log an error or ignore the error. See https://stackoverflow.com/questions/74907704/is-there-a-github-actions-warning-state
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
Fair point, Adam. leaving it as-is for now.
👍 2
Ack