Skip to content
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

Use the version catalog as the source of truth for plugin IDs #648

Merged
merged 7 commits into from
Jan 22, 2025

Conversation

VahidGarousi
Copy link
Contributor

The IDs stated in the build-logic build script must exactly match the plugin IDs in the version catalog file. This solution reduces the inherent duplication.

To avoid any IDE errors about missing plugin accessors when adding new plugins to the build-logic script, adding the new ID in the version catalog first is recommended, then invoking Gradle (sync) to generate the accessor classes.

….gradle.lint`

Aligned with issue serbelga#646, replaced the direct plugin ID declaration with the version catalog alias `libs.plugins.dev.sergiobelda.gradle.lint`. This ensures the plugin IDs in the build logic match the version catalog as the single source of truth, reducing duplication and improving maintainability.
….gradle.spotless`

Aligned with issue serbelga#646, replaced the direct plugin ID declaration with the version catalog alias `libs.plugins.dev.sergiobelda.gradle.lint`. This ensures the plugin IDs in the build logic match the version catalog as the single source of truth, reducing duplication and improving maintainability.
….gradle.detekt`

Aligned with issue serbelga#646, replaced the direct plugin ID declaration with the version catalog alias `libs.plugins.dev.sergiobelda.gradle.lint`. This ensures the plugin IDs in the build logic match the version catalog as the single source of truth, reducing duplication and improving maintainability.
….gradle.dependency-graph-generator`

Aligned with issue serbelga#646, replaced the direct plugin ID declaration with the version catalog alias `libs.plugins.dev.sergiobelda.gradle.lint`. This ensures the plugin IDs in the build logic match the version catalog as the single source of truth, reducing duplication and improving maintainability.
….gradle.common.ui`

Aligned with issue serbelga#646, replaced the direct plugin ID declaration with the version catalog alias `libs.plugins.dev.sergiobelda.gradle.lint`. This ensures the plugin IDs in the build logic match the version catalog as the single source of truth, reducing duplication and improving maintainability.
….gradle.common.library.android`

Aligned with issue serbelga#646, replaced the direct plugin ID declaration with the version catalog alias `libs.plugins.dev.sergiobelda.gradle.lint`. This ensures the plugin IDs in the build logic match the version catalog as the single source of truth, reducing duplication and improving maintainability.
….gradle.base`

Aligned with issue serbelga#646, replaced the direct plugin ID declaration with the version catalog alias `libs.plugins.dev.sergiobelda.gradle.lint`. This ensures the plugin IDs in the build logic match the version catalog as the single source of truth, reducing duplication and improving maintainability.
@VahidGarousi
Copy link
Contributor Author

I checked this gradle task and It's Ok.

What should I do?
image

@serbelga
Copy link
Owner

I think build is failing because is trying to use a GitHub secret on a forked repository

@serbelga
Copy link
Owner

I will run locally these tasks and update the trigger to not use this secret on pull request that comes from a fork

@VahidGarousi
Copy link
Contributor Author

I think build is failing because is trying to use a GitHub secret on a forked repository

You are right, I have seen this type of error on another project

@serbelga serbelga merged commit 47014da into serbelga:main Jan 22, 2025
1 check failed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants