feat: enforce changelog entry via CI check

[Mounil2005]

Contributor checklist

• This pull request is on a separate branch and not the main branch
• I have tested my code with the ./gradlew lintKotlin detekt test command as directed in the testing section of the contributing guide

---

Description

Adds a new GitHub Actions workflow ci_changelog_check.yaml that enforces changelog discipline on every PR targeting main.

What changed:

• .github/workflows/ci_changelog_check.yaml -> new workflow file

How it works:

• Uses tj-actions/changed-files to detect whether CHANGELOG.md was modified in the PR
• If it was not updated, the workflow fails with a clear error message pointing contributors to update the changelog before merging
• Supports a no-changelog label that maintainers can apply to skip the check for CI fixes, typo corrections, or dependency bumps
• Triggers on opened, reopened, synchronize, labeled, and unlabeled so adding/removing the label immediately re-evaluates the check

Testing:
This is a pure YAML workflow file, the lintKotlin detekt test command does not apply. The check can be verified by opening a test PR without a changelog update and confirming it fails.

Related issue

No related issue, this is a self-initiated improvement to the CI pipeline.

[github-actions]

Thank you for the pull request! 💙🩵

The Scribe-Android team will do our best to address your contribution as soon as we can. The following are some important points:

• Those interested in developing their skills and expanding their role in the community should read the mentorship and growth section of the contribution guide
• If you're not already a member of our public Matrix community, please consider joining!
  • We'd suggest that you use the Element client as well as Element X for a mobile app
  • Join the General and Android rooms once you're in
• Also consider attending our bi-weekly Saturday developer syncs!
  • Details are shared in the General room on Matrix each Wednesday before the sync
  • It would be great to meet you 😊

Note

Scribe uses Conventional Comments in reviews to make sure that communication is as clear as possible.

[github-actions]

Maintainer Checklist

The following is a checklist for maintainers to make sure this process goes as well as possible. Feel free to address the points below yourself in further commits if you realize that actions are needed :)

• Tests for changes have been written and the unit test, linting and formatting workflows within the PR checks do not indicate new errors in the files changed

  • Tests may need to be reran as they're at times not deterministic

• The CHANGELOG has been updated with a description of the changes for the upcoming release and the corresponding issue (if necessary)

[andrewtavis]

@axif0, @DeleMike: What's your two's opinion on this? I think that it could be nice if we could eventually migrate away from the maintainer checklists that we have for projects. Each checklist that we have has one box for tests passing and having been written as well as a box that the changelog has been updated. We haven't been doing the changelog for Scribe-Android yet, and tend to write the changelog for Scribe-Data as PRs with major changes come in.

Would be great if the testing checkbox was automatic given tests in CI and coverage being maintained, especially for the files being changed (maybe via tj-actions/changed-files@v44 as is used here, but the focus on overall coverage for now is fine). For the changelog, I think there could be a way to automate this a bit better, but I'm just not sure if this is exactly what we're looking for. Ideally we'd come up with something that all of the projects could use 😊

[Mounil2005]

@axif0, @DeleMike: What's your two's opinion on this? I think that it could be nice if we could eventually migrate away from the maintainer checklists that we have for projects. Each checklist that we have has one box for tests passing and having been written as well as a box that the changelog has been updated. We haven't been doing the changelog for Scribe-Android yet, and tend to write the changelog for Scribe-Data as PRs with major changes come in.

Would be great if the testing checkbox was automatic given tests in CI and coverage being maintained, especially for the files being changed (maybe via tj-actions/changed-files@v44 as is used here, but the focus on overall coverage for now is fine). For the changelog, I think there could be a way to automate this a bit better, but I'm just not sure if this is exactly what we're looking for. Ideally we'd come up with something that all of the projects could use 😊

Thanks for the detailed feedback! A few thoughts on the points raised:

Cross-project reusability - happy to convert this into a reusable workflow using workflow_call so it can live in scribe-org/.github and be called from all Scribe projects with minimal config. That would make it a one-liner to opt in from any repo.

Hard-fail vs. soft warning - since Scribe-Android hasn't been enforcing changelog entries yet, a hard fail might be too abrupt for contributors. One middle ground: keep the CI failure but also have the workflow post a PR comment when it fails, explaining exactly what to add and where (e.g. "Please add an entry under the latest version heading in CHANGELOG.md"). That way contributors aren't just staring at a red check with no guidance.

Test checkbox automation - great idea as a follow-up. tj-actions/changed-files could be used to check whether changed .kt files have corresponding test coverage. Happy to explore that in a separate PR once the changelog piece is settled.

Would it make sense to first agree on the changelog enforcement approach here, then tackle reusability and test automation as follow-ups? Would also love to hear what @axif0 and @DeleMike think!

[DeleMike]

Hi @Mounil2005, this is a good PR; it will have its benefits. I do think that having a PR that checks for a compulsory changelog entry is good.

As @andrewtavis noted, this is a nice-to-have and not yet a priority.

[DeleMike]

How about looking into adding more test coverage for the app? is that something you can work on?

[Mounil2005]

How about looking into adding more test coverage for the app? is that something you can work on?

Thanks for the suggestion @DeleMike! I would surely love to work on that.
After looking into the codebase, the biggest gaps are:

Core keyboard handlers: AutocompletionHandler, BackspaceHandler, KeyHandler, SpaceKeyProcessor, and SuggestionHandler are completely untested despite being the heart of the app. These are pure logic so unit tests with the existing JUnit 5 + Mockk setup would work well.
Data managers : ConjugateDataManager, GenderDataManager, PluralFormsManager, Trie etc. all have zero coverage. Robolectric is already declared in the project so SQLite-backed ones can be tested without an emulator.
Language-specific helpers: 8 language implementations, none tested. Even basic smoke tests to verify each language loads and returns valid data would be a solid start.
Conjugate flavor: CI already runs connectedConjugateDebugAndroidTest but there are no actual test files for it, so that job is effectively a no-op.

which one should i move ahead with?

[DeleMike]

Okay, kindly wait for @angrezichatterbox to get back to you on this.

Or @andrewtavis, what are your thoughts on this?

[Mounil2005]

Hi @Mounil2005, this is a good PR; it will have its benefits. I do think that having a PR that checks for a compulsory changelog entry is good.

As @andrewtavis noted, this is a nice-to-have and not yet a priority.

Thanks @DeleMike! Completely understand it's not a top priority right now. Since the implementation is already in place though, it might be a nice opportunity to merge it as a quiet foundation, it won't change anything for existing contributors and can always be tightened up later when the team feels ready.
I was also thinking of extending it to post a friendly PR comment when the check fails, pointing contributors to exactly where and how to add a changelog entry. That way it feels more like a helpful nudge than a hard blocker.
Of course, totally open to whatever direction the team prefers!

[DeleMike]

No problem @Mounil2005, let’s wait for @andrewtavis decision.