Proposal for Deprecating `check-github-workflows` and `check-renovate` Hooks

[vivodi]

Thank you for the thoughtful response on issue #583 and for being open to a more detailed discussion. I appreciate the points you @sirosen raised. This proposal aims to address them directly and articulate a clear path forward that I believe will benefit both the users and the project.

1. A Clear, Two-Phase Deprecation Plan

I agree that a sudden removal would be disruptive. A graceful deprecation process is essential to accommodate existing users. I propose the following two-phase plan:

• Phase 1: Announce Deprecation and Implement Warnings. In the next release, we can officially begin the deprecation process. This involves two key actions:

  • Update Documentation: The documentation will be updated to clearly mark the check-github-workflows and check-renovate hooks as deprecated. It will recommend migrating to actionlint and renovate-config-validator and explain the rationale.
  • Implement Runtime Warnings: A clear, non-disruptive deprecation warning will be added to the output when these hooks are used. The message will inform users of the deprecation, suggest the alternative tool, and reference the future removal.

• Phase 2: Final Removal. After a significant grace period to allow for user migration—for instance, one year from the deprecation release—the hooks can be completely removed from the project. This extended timeline provides ample opportunity for all users to transition at their own pace.

This phased approach ensures that existing users are well-informed and have sufficient time to transition, minimizing any negative impact.

2. Long-Term User Benefits of Migrating

The primary motivation for this proposal is the significant long-term benefit for users, who will be guided towards more powerful and purpose-built tools.

• More Comprehensive Validation: Tools like actionlint offer far more than just schema validation; they perform deep static analysis, checking for syntax errors, logical issues, and best practice violations in GitHub Actions workflows. Similarly, renovate-config-validator is the official, first-party tool for validating Renovate configurations. These tools help users catch a wider range of potential errors before they cause problems in production.
• Staying Current with Official Tooling: The official renovate-config-validator is maintained in lockstep with Renovate Bot itself. This is a crucial advantage. With check-renovate, there is often a delay between the introduction of new Renovate features and the corresponding schema update in check-jsonschema. This can lead to validation failures where users trying to adopt new Renovate functionalities are blocked by an outdated schema, forcing them to wait for a new release of check-jsonschema. Migrating to the official tool eliminates this friction entirely.

3. Benefits for the check-jsonschema Project

While the primary motivation is user benefit, deprecating these specialized hooks also brings clear advantages to the check-jsonschema project itself.

• Focus on the Core Mission: check-jsonschema excels as a general-purpose JSON Schema validator. Freeing up maintainer time and resources allows for more focus on improving the core functionality of the tool, developing other valuable features, and addressing general issues. This strengthens the project's primary value proposition.
• Benefit to the Broader Open-Source Community: This change benefits the entire open-source community by avoiding duplicated effort for a subordinate substitute and ensuring that support requests are handled by the respective experts for each tool.

In summary, I believe a well-communicated, gradual deprecation of these hooks is in the best interest of both the users and the check-jsonschema project. It guides users toward superior tooling while allowing check-jsonschema to focus on its core strengths.

I hope this detailed proposal clarifies my perspective, and I would be happy to discuss this further.