search

varabyte / kobweb

A modern framework for full stack web apps in Kotlin, built upon Compose HTML
https://kobweb.varabyte.com
Apache License 2.0
1.41k stars 64 forks source link

Create update-gradle-wrapper.yml to automate the process of updating Gradle wrapper #531

Closed EchoEllet closed 2 months ago

EchoEllet commented 2 months ago

This PR doesn't do anything, it use all the code from Update Gradle Wrapper Action from the GitHub marketplace, we often have too many versions for different tools and dependencies, this would make the process of keep tracking of all of them and ensuring them they are up to date to benefit from latest bug fixes, improvements, features and security fixes is a more time consuming and sometimes we forgot about them

If you read this link:

Gradle is under heavy development, with new releases available every few weeks. Projects that stick to old Wrapper versions can't > benefit from the tons of features and bug fixes being rolled out.

Updating the build system only once or twice per year might become a tedious task. You will need to walk through longer changelogs > and handle any breaking change. Updating frequently helps do less work, take advantage of new features earlier and safely drop > deprecated functionality.

This action runs automatically at the declared schedule and creates Pull Requests with detailed information about the version update.

It won't automatically update the Gradle wrapper version, it will send a PR and have to manually accept or reject the change, and it will be scheduled

bitspittle commented 2 months ago

I appreciate the intention behind this suggestion, but it strikes me as something that will generate noise. Both in pinging us with PRs when we're otherwise busy, but also generating a bunch of extra jobs in our CI pipeline history.

Updating the gradle wrapper version is so trivial to do, and we've been doing it on our own terms, with no issues so far. I'm really hesitant to take a change that doesn't solve a problem that we've actually had.

EchoEllet commented 2 months ago

I appreciate the intention behind this suggestion, but it strikes me as something that will generate noise. Both in pinging us with PRs when we're otherwise busy, but also generating a bunch of extra jobs in our CI pipeline history.

Updating the gradle wrapper version is so trivial to do, and we've been doing it on our own terms, with no issues so far. I'm really hesitant to take a change that doesn't solve a problem that we've actually had.

It doesn't necessarily fix an issue, but for me, it's useful to have, especially when having too many projects with different frameworks and languages

But what would be really useful is to use a lint tool just like eslint in JS ecosystem, I heard of KtLint but only start using it recently, it use all the rules and guidelines from official Kotlin but even more strict and can catch some quality and issues that the compiler or the Gradle build task won't

It also has a plugin for Intellij and can be used in CI (just by using the build task or its own task)

It has a Gradle plugin, and you only have to fix the issues and the warrings it gives you the first time, and then it should give you the warrning in the IDE