Documentation-only contributions and CI workflow

[atharmshaikh]

Enhancement Proposal

Description

I wanted to ask about the preferred workflow for documentation-only contributions.

At the moment, Android CI workflows (which require signing secrets) are triggered even when a PR only changes documentation files like the README or other markdown. This suggestion is only about contributor workflow and clarity — it does not propose changing any app behavior or weakening security.

---

Motivation

While submitting a recent documentation-only change in #97 , the Android build and signing workflows were triggered in a forked PR. Since forked PRs can’t access upstream secrets, the CI checks showed expected failures that weren’t related to the documentation change itself.

This is understandable and expected, but it can be a bit confusing for contributors who are only trying to improve docs. I thought it might be useful to clarify the recommended approach for docs-only changes, or adjust CI scope if that makes sense.

---

Proposed Solution

Any of the following approaches would work — happy to follow whatever you prefer.

1. Use issues for small documentation changes
   For minor updates (README formatting, wording, structure), contributors could open a documentation issue instead of a PR, allowing you to apply the change directly without triggering Android CI.

2. Allow documentation PRs with expected CI failures explained
   Continue accepting docs PRs, with contributors briefly explaining that CI failures are expected in forked PRs due to missing signing secrets, and that no app code is affected.

3. Run Android CI only when relevant files change
   Use path-based conditions so Android build/signing workflows only run when application files change. For example:

   • Run Android CI when changes include:
     app/**, *.kt, *.java, *.gradle, *.xml
   • Skip Android CI when changes are limited to:
     README*, *.md, docs/**, documentation assets (images/screenshots)

   This would keep all existing branch protections and security checks (CodeQL, Codacy, etc.) intact, while avoiding unnecessary Android CI runs for documentation-only updates.

These are just ideas — I’m fine with whichever approach fits best.

---

Alternatives Considered

• Keeping the current setup as-is and relying on manual review for docs PRs (which already works).
• Always running Android CI, even for docs-only changes, and accepting the extra noise.

Both are reasonable; this is mainly about setting expectations and reducing confusion.

---

Additional Context

This comes from a recent documentation contribution where:

• The debug build was verified successfully in a fork with secrets configured.
• Upstream CI failures were due only to fork secret restrictions, not the documentation change.

No security checks are being skipped or reduced.

---

Acceptance Criteria

• Preferred workflow for documentation-only changes is clarified
• Contributors know what to expect when submitting docs updates
• No reduction in CI coverage or signing security for application code

---

Dependencies

None.

---

Checklist

• Checked for existing similar issues
• Based on a recently merged documentation PR
• Happy to help if any follow-up changes are needed

---

Additional Notes:
This is a non-urgent, forward-looking question based on a recent docs contribution.
Just wanted to align on what works best for future documentation updates.