-
-
Notifications
You must be signed in to change notification settings - Fork 4
Added GitHub actions for automated releases #22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
- chore: Bumped up the versions - chore: Fixed linting issues
WalkthroughThis update introduces a new GitHub Actions workflow for publishing artifacts, updates release workflow and dependency versions, modifies build and publishing configurations, and makes minor documentation, formatting, and metadata adjustments across several files. It also begins tracking Changes
Sequence Diagram(s)sequenceDiagram
participant GitHub
participant Workflow (Publish)
participant Gradle
participant MavenCentral
GitHub->>Workflow (Publish): Release published event
Workflow (Publish)->>Workflow (Publish): Checkout code
Workflow (Publish)->>Workflow (Publish): Setup JDK 21
Workflow (Publish)->>Gradle: Run publish command (with secrets)
Gradle->>MavenCentral: Publish artifacts (with signing, credentials)
MavenCentral-->>Gradle: Acknowledge publication
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
🧪 Generate unit tests
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 2
🔭 Outside diff range comments (1)
triggerx/src/main/java/com/meticha/triggerx/permission/TriggerXPermissionComposable.kt (1)
94-101: Potential NPE oncurrentPermission!!
permissionState.currentPermissionis force-unwrapped inside the callback.
If the launcher returns whilecurrentPermissionisnull, the app will crash.- when { - isGranted(context, permissionState.currentPermission!!) -> { - permissionState.allRequiredGranted() - permissionState.next() - } - - else -> handlePermissionDenial(permissionState) - } + permissionState.currentPermission?.let { current -> + if (isGranted(context, current)) { + permissionState.allRequiredGranted() + permissionState.next() + } else { + handlePermissionDenial(permissionState) + } + } ?: handlePermissionDenial(permissionState)
🧹 Nitpick comments (7)
.idea/misc.xml (1)
1-6: Re-evaluate committing IDE-specific stateCommitting
.ideametadata (especially framework-detection exclusions) can create churn for contributors using different IDE versions or non-IntelliJ editors. Consider adding this file to.gitignore(or moving the setting toworkspace.xml) unless the team explicitly wants it under version control..github/workflows/release.yaml (1)
84-85: Consider using organization email for git configuration.Using a personal email (
[email protected]) in the automated workflow might not be ideal for organization repositories. Consider using a generic organization email or GitHub's noreply email.- git config --global user.email "[email protected]" - git config --global user.name "Cavin" + git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com" + git config --global user.name "github-actions[bot]".github/workflows/publish.yml (1)
24-24: Fix missing newline at end of file.Static analysis correctly identifies a missing newline character at the end of the file.
ORG_GRADLE_PROJECT_signingInMemoryKey: ${{ secrets.GPG_KEY_CONTENTS }} +triggerx/src/main/java/com/meticha/triggerx/permission/TriggerXPermissionComposable.kt (4)
118-126: User-visible strings are hard-codedThe rationale dialog strings are embedded directly in code.
For localisation and accessibility, move them tostrings.xml.Example:
- ShowPopup( - message = "Permissions are required to proceed further", + ShowPopup( + message = stringResource(R.string.triggerx_permission_rationale),Same applies to
"Cancel","Grant Permission", etc.
148-155: Long concatenated message is hard to maintainInstead of multiple
+concatenations, use a raw triple-quoted string or an external resource:val guidanceMsg = """ For alarms to reliably appear when the app is in the background, '$appName' needs an additional permission on some phones (Xiaomi, Oppo, Vivo, …). Settings → Apps → '$appName' → Other permissions → enable “Display pop-up windows while running in the background”. This reminder is shown once if you click ‘Acknowledge’. """.trimIndent()Improves readability and avoids accidental whitespace issues.
178-179: Redundant emptyelsebranch
else -> {}adds no behaviour and can be dropped to reduce noise.- else -> {} + // no-op
241-258: Dialog copy should be single-sourcedStrings like
"Permission is required" / "Grant Permission"are repeated across dialogs.
Extract them tostrings.xmlto avoid future inconsistencies and to enable translations.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (13)
.github/workflows/publish.yml(1 hunks).github/workflows/release.yaml(2 hunks).gitignore(0 hunks).idea/misc.xml(1 hunks)gradle.properties(1 hunks)gradle/libs.versions.toml(1 hunks)gradle/wrapper/gradle-wrapper.properties(1 hunks)triggerx/build.gradle.kts(2 hunks)triggerx/src/main/java/com/meticha/triggerx/permission/PermissionLifeCycleCheckEffect.kt(2 hunks)triggerx/src/main/java/com/meticha/triggerx/permission/TriggerXPermissionComposable.kt(7 hunks)triggerx/src/main/java/com/meticha/triggerx/permission/TriggerXPermissionManager.kt(7 hunks)triggerx/src/main/java/com/meticha/triggerx/preference/TriggerXPreference.kt(1 hunks)triggerx/src/main/java/com/meticha/triggerx/services/TriggerXForegroundService.kt(1 hunks)
💤 Files with no reviewable changes (1)
- .gitignore
🧰 Additional context used
🪛 YAMLlint (1.37.1)
.github/workflows/publish.yml
[error] 24-24: no new line character at the end of file
(new-line-at-end-of-file)
🔇 Additional comments (15)
triggerx/src/main/java/com/meticha/triggerx/preference/TriggerXPreference.kt (1)
58-60: Documentation clarified ‑ looks goodThe updated KDoc sentence now explicitly mentions that the method can persist the optional notification title & message, which aligns with the implementation. No further action required.
gradle/libs.versions.toml (1)
9-15: No conflicting Hilt versions in build scriptsA search across all
*.gradle*and*.gradle.ktsfiles for hard-codedcom.google.dagger:hilt-android(-compiler)and Hilt Gradle plugin version declarations returned no matches outside ofgradle/libs.versions.toml. The version catalog entry (hilt = "2.56.1") is the single source of truth—no further alignment is required.gradle/wrapper/gradle-wrapper.properties (1)
1-4: Confirm downgrade to Gradle 8.11.1 is intentionalMoving from 8.13 → 8.11.1 reverses two minor releases: potential bug-fixes & API additions used by recent AGP versions could break. Ensure:
./gradlew helpruns cleanly locally/CI.- AGP 8.10 stays fully supported on 8.11.1 (it usually is, but worth a quick smoke).
No code changes needed if the downgrade is deliberate.
triggerx/src/main/java/com/meticha/triggerx/services/TriggerXForegroundService.kt (1)
185-186: Channel description phrasing improvedThe new description is clearer/less app-specific. 👍
triggerx/src/main/java/com/meticha/triggerx/permission/PermissionLifeCycleCheckEffect.kt (2)
29-29: Documentation improvement looks good.The rephrased KDoc comment is more concise and direct while maintaining clarity.
38-38: Formatting consistency improvement.Removing the indentation aligns with standard KDoc formatting practices.
.github/workflows/release.yaml (2)
10-10: Version bump looks good.The version increment from 0.0.8 to 0.0.9 is appropriate for the release workflow.
19-19: Good upgrade to checkout action.Upgrading from
actions/checkout@v3toactions/checkout@v4provides better security and features.gradle.properties (1)
1-8: Gradle configuration looks well-structured.The properties file includes appropriate settings:
- Adequate JVM heap size (2GB) for Android builds
- UTF-8 encoding for proper character handling
- AndroidX usage for modern Android development
- Official Kotlin code style enforcement
- Non-transitive R class for improved build performance
All configurations are standard and appropriate for an Android library project.
triggerx/src/main/java/com/meticha/triggerx/permission/TriggerXPermissionManager.kt (3)
145-149: Good formatting improvement for when branches.Compacting the single-line when branches improves readability while maintaining the same functionality.
166-211: Consistent formatting improvement in createPermissionIntent.The compacted when branches make the code more readable and consistent with the formatting style used elsewhere in the function.
243-243: Minor comment punctuation fix.Adding the comma improves the grammatical correctness of the comment.
.github/workflows/publish.yml (2)
1-18: Well-configured publish workflow.The workflow is properly set up for automated Maven Central publishing:
- Appropriate trigger on release events
- Modern JDK 21 with reliable Zulu distribution
- Correct Gradle command for Maven Central publishing
- Proper use of secrets for authentication and signing
19-24: Environment variables properly configured.The environment variables correctly map GitHub secrets to the expected Gradle properties for Maven Central publishing and artifact signing.
triggerx/build.gradle.kts (1)
110-116: Duplicate version & malformed license distributionThe
<version>element repeats the same string already supplied viacoordinates.
Also, Maven Central expects the<license><distribution>tag to be eitherrepoormanual, not a URL.- version = "0.0.9" + // Version comes from coordinates ⇒ can be dropped or interpolated + version = project.version.toString() @@ - distribution = "https://www.apache.org/licenses/LICENSE-2.0.txt" + distribution = "repo"Avoids warnings during the
publishToMavenCentralvalidation step.
| mavenPublishing { | ||
| publishToMavenCentral() | ||
|
|
||
| signAllPublications() | ||
|
|
||
|
|
||
| coordinates("com.meticha", "triggerx", "0.0.9") | ||
|
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Hard-coding coordinates duplicates existing Gradle properties
group and version are usually supplied via gradle.properties or a root‐level versionCatalog.
Duplicating them here risks divergence on the next bump.
- coordinates("com.meticha", "triggerx", "0.0.9")
+ // Re-use the project’s canonical values
+ coordinates(project.group.toString(), "triggerx", project.version.toString())This keeps the build single-sourced and avoids accidental mismatches between publishing and build metadata.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| mavenPublishing { | |
| publishToMavenCentral() | |
| signAllPublications() | |
| coordinates("com.meticha", "triggerx", "0.0.9") | |
| mavenPublishing { | |
| publishToMavenCentral() | |
| signAllPublications() | |
| // Re-use the project’s canonical values | |
| coordinates( | |
| project.group.toString(), | |
| "triggerx", | |
| project.version.toString() | |
| ) | |
| } |
🤖 Prompt for AI Agents
In triggerx/build.gradle.kts around lines 97 to 104, the Maven publishing
coordinates are hard-coded, duplicating values that should come from existing
Gradle properties like group and version. Remove the explicit coordinates call
and instead reference the group and version properties already defined in
gradle.properties or the root version catalog to keep the build configuration
single-sourced and consistent.
| alias(libs.plugins.kotlin.compose) | ||
| alias(libs.plugins.spotless) | ||
| id("com.vanniktech.maven.publish") version "0.32.0" | ||
| id("com.vanniktech.maven.publish") version "0.34.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🛠️ Refactor suggestion
Avoid mixing version-catalog aliases with an explicit plugin declaration
Every other plugin is declared through the version-catalog (alias(libs.plugins.…)), whereas com.vanniktech.maven.publish is hard-coded with a version string.
Mixing the two styles makes upgrades easy to miss.
- id("com.vanniktech.maven.publish") version "0.34.0"
+ alias(libs.plugins.vanniktech.maven.publish)Add the plugin to libs.versions.toml and keep all versions in a single place.
🤖 Prompt for AI Agents
In triggerx/build.gradle.kts at line 21, the plugin
"com.vanniktech.maven.publish" is declared with a hard-coded version string,
which is inconsistent with other plugins declared via version-catalog aliases.
To fix this, add the plugin and its version to the libs.versions.toml file and
then replace the explicit declaration with the corresponding alias from the
version catalog to centralize version management.
Summary by CodeRabbit
Chores
Style
Documentation