Add Scheduled Cleanup 🧹

[Pankraz76]

Please DO NOT FORCE PUSH. Don't worry about messy history, it's easier to do code review if we can tell what happened after the review, and force pushing breaks that.

Please make sure that your PR allows edits from maintainers. Sometimes it's faster for us to just fix something than it is to describe how to fix it.

After creating the PR, please add a commit that adds a bullet-point under the [Unreleased] section of CHANGES.md, plugin-gradle/CHANGES.md, and plugin-maven/CHANGES.md which includes:

• a summary of the change
• either
  • a link to the issue you are resolving (for small changes)
  • a link to the PR you just created (for big changes likely to have discussion)

If your change only affects a build plugin, and not the lib, then you only need to update the plugin-foo/CHANGES.md for that plugin.

If your change affects lib in an end-user-visible way (fixing a bug, updating a version) then you need to update CHANGES.md for both the lib and all build plugins. Users of a build plugin shouldn't have to refer to lib to see changes that affect them.

This makes it easier for the maintainers to quickly release your changes :)

[Pankraz76]

kindly request some feedback if you got some time.

[Pankraz76]

this might be wrong? we just need schedule right?

Suggested change

	push:
	branches: [main]

[Pankraz76]

Runs the workflow every time someone pushes to the main branch

this could help to immediately find violating code and might apply the tiny big bangs instead of really big once, when doing in longer period.

[nedtwigg]

This is a good start. What do you think about this approach?

Rather than having an error-prone.yml file and a rewrite.yml file, we just have a scheduled-cleanup.yml

The first part runs commands that hopefully never fail (commands similar to spotlessApply). If the command succeeds and git status is dirty, then it creates a branch scheduled-cleanup-YYYY-MM-DD, commits to that branch, pushes, and opens a PR.

The second part runs commands that might fail (e.g spotbugsMain). When those fail, we get a red X, and it will require manual intervention from somebody to notice and take action to fix. That is okay. It's okay for quality checks like this to get missed and only fixed intermittently in batches. There is a downside to this, but the upside is that each increment of work can get incorporated with less back and forth.

[Pankraz76]

Rather than having an error-prone.yml file and a rewrite.yml file, we just have a scheduled-cleanup.yml

Yes, the DRY violations (especially in the PR title) make no sense.

spotbugsMain

Mentioning this makes me wonder if we should move this as well. We do run it (somehow—I don't really know the details—but I assume it follows the convention principle of the tool), but not on the first call, like spotless. Otherwise, we could end up starting 15 builds in the worst case with non-compliant code, which would make the build wasted, right?

• https://github.com/Pankraz76/spotless/pull/8/commits
• Pankraz76@111e934

[Pankraz76]

The first part runs commands that hopefully never fail (commands similar to spotlessApply). If the command succeeds and git status is dirty, then it creates a branch scheduled-cleanup-YYYY-MM-DD, commits to that branch, pushes, and opens a PR.

understand this nice (auto patching) but how is this implemented id see the commands?