fix(ci): Update release-notes-check and presto-release-prepare actions

[unidevel]

Description

1. presto-release-tools can not be fetched due to maven central publishing limitation
2. check maven central publishing requirements
3. add required <name> field to presto-lance

Motivation and Context

Depends on PRs:

• [fix] Add release notes summary to a file when it is too big presto-release-tools#65
• [fix] Add missing name for publishing presto-release-tools#64
• [fix] Publish executable jar as github release presto-release-tools#63
• [fix] Update the re pattern for the release notes section presto-release-tools#62

Impact

CI

Test Plan

Tested with:

1. release note check action: https://github.com/prestodb/presto/actions/runs/23815800338/job/69414865062?pr=27466
2. maven central publishing requirements check: https://github.com/unix280/presto/actions/runs/23812452401/job/69402863222#step:8:76
3. Prepare release action in presto => https://github.com/unix280/presto/actions/runs/23812844511
4. Release notes PR => docs: Add release notes for 0.297 unix280/presto#52
5. Release notes missing list file => https://github.com/unix280/presto/blob/release-notes-0.297/release-notes-missing-0.297.md

Contributor checklist

• Please make sure your submission complies with our contributing guide, in particular code style and commit standards.
• PR description addresses the issue accurately and concisely. If the change is non-trivial, a GitHub Issue is referenced.
• Documented new properties (with its default value), SQL syntax, functions, or other functionality.
• If release notes are required, they follow the release notes guidelines.
• Adequate tests were added if applicable.
• CI passed.
• If adding new dependencies, verified they have an OpenSSF Scorecard score of 5.0 or higher (or obtained explicit TSC approval for lower scores).

Release Notes

Please follow release notes guidelines and fill in the release notes below.

== NO RELEASE NOTE ==

Summary by Sourcery

Update CI and release scripts to retrieve presto-release-tools from GitHub releases using a configurable version instead of Maven Central.

CI:

• Change release-notes-check workflow to download the presto-release-tools executable directly from GitHub releases and run it from a temporary path.
• Make the release-notes-check workflow use a configurable RELEASE_TOOLS_VERSION with a default of 0.13.

Deployment:

• Update release preparation workflow and release-notes script to use a configurable RELEASE_TOOLS_VERSION (default 0.13) and fetch presto-release-tools from GitHub releases instead of Maven.

Chores:

• Align release tooling version and retrieval method across CI workflows and release scripts.

[unidevel]

Waiting for prestodb/presto-release-tools#64 merged and a new version of presto-release-tools published.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Update CI workflows and release script to download presto-release-tools directly from GitHub releases using a configurable RELEASE_TOOLS_VERSION (default 0.13), and ensure that version is consistently propagated across release-related jobs.

Sequence diagram for updated release-notes-check workflow tool download

sequenceDiagram
    actor Developer
    participant GitHub as GitHub
    participant ReleaseNotesCheckWorkflow as Release_notes_check_workflow
    participant Runner as GitHub_Actions_runner
    participant GitHubReleases as GitHub_releases_presto_release_tools
    participant PrestoReleaseTools as Presto_release_tools_executable

    Developer->>GitHub: Open_or_update_pull_request
    GitHub-->>ReleaseNotesCheckWorkflow: Trigger_workflow_on_pull_request
    ReleaseNotesCheckWorkflow->>Runner: Start_job_check_release_note

    Runner->>Runner: Set_env_RELEASE_TOOLS_VERSION
    note over Runner: RELEASE_TOOLS_VERSION = vars.RELEASE_TOOLS_VERSION_or_0_13

    Runner->>GitHubReleases: GET_presto_release_tools_${RELEASE_TOOLS_VERSION}
    GitHubReleases-->>Runner: Download_jar_to_tmp_presto_release
    Runner->>Runner: chmod_755_tmp_presto_release

    Runner->>GitHub: Call_GraphQL_API_get_PR_body
    GitHub-->>Runner: Return_PR_body

    Runner->>PrestoReleaseTools: echo_PR_body_pipe_to_tmp_presto_release_check_release_notes
    PrestoReleaseTools-->>Runner: Validation_result
    Runner-->>ReleaseNotesCheckWorkflow: Mark_job_success_or_failure
    ReleaseNotesCheckWorkflow-->>GitHub: Report_status_on_pull_request

Loading

Flow diagram for RELEASE_TOOLS_VERSION resolution across CI and script

flowchart TD
    A[GitHub_repository_variable_vars.RELEASE_TOOLS_VERSION] --> B{vars.RELEASE_TOOLS_VERSION_set?}
    B -- Yes --> C[Workflow_env_RELEASE_TOOLS_VERSION = vars.RELEASE_TOOLS_VERSION]
    B -- No --> D[Workflow_env_RELEASE_TOOLS_VERSION = 0.13]

    C --> E[Job_env_in_release_notes_check_and_presto_release_prepare]
    D --> E

    E --> F[Step_env_RELEASE_TOOLS_VERSION_exported_to_runner]
    F --> G[Script_release_notes.sh_env_RECEIVES_RELEASE_TOOLS_VERSION]

    G --> H{Script_env_RELEASE_TOOLS_VERSION_set?}
    H -- Yes --> I[Script_uses_existing_RELEASE_TOOLS_VERSION]
    H -- No --> J[Script_sets_RELEASE_TOOLS_VERSION = 0.13]

    I --> K[curl_download_from_GitHub_releases_using_RELEASE_TOOLS_VERSION]
    J --> K
    K --> L[java_runs_presto_release_tools_with_release_notes_command]

Loading

File-Level Changes

Change	Details	Files
Switch release-notes CI check from Maven Central to GitHub releases with configurable presto-release-tools version.	Set RELEASE_TOOLS_VERSION in workflow env to use repository variable if present, otherwise default to 0.13. Replace Maven dependency:get step with curl download of presto-release-tools executable JAR from GitHub releases into /tmp/presto_release. Make downloaded presto-release-tools executable and use it directly in the check-release-notes step. Remove chmod and path usage for the Maven local-repository copy of presto-release-tools.	.github/workflows/release-notes-check.yml
Update release-notes shell script to fetch presto-release-tools from GitHub releases with a default version and executable permissions.	Introduce RELEASE_TOOLS_VERSION variable in the script, defaulting to 0.13 when not provided in the environment. Change curl URL from Sonatype/Maven redirect to GitHub releases URL parameterized by RELEASE_TOOLS_VERSION. Ensure the downloaded jar is written to /tmp/presto_release and chmod 755 is applied before running. Continue to run the release-notes command via java -jar using the downloaded executable.	src/release/release-notes.sh
Propagate RELEASE_TOOLS_VERSION into the presto-release-prepare workflow so release notes generation uses the same tool version as CI.	Define RELEASE_TOOLS_VERSION at the workflow env level, sourcing from GitHub Actions vars with default 0.13. Export RELEASE_TOOLS_VERSION into the environment of the "Create release notes pull request" step, alongside JVM_OPTS. Rely on release-notes.sh picking up RELEASE_TOOLS_VERSION from the environment to download the matching presto-release-tools release.	.github/workflows/presto-release-prepare.yml

Possibly linked issues

• #check_release_note pipeline failed: The PR changes how presto-release-tools is fetched in the check_release_note workflow, resolving the Maven CI failure described.

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've found 1 issue

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location path=".github/workflows/release-notes-check.yml" line_range="8" />
<code_context>
   MAVEN_OPTS: ${{ vars.MAVEN_OPTS }}
   GIT_CI_USER: ${{ vars.GIT_CI_USER || 'prestodb-ci' }}
   GIT_CI_EMAIL: ${{ vars.GIT_CI_EMAIL || 'ci@lists.prestodb.io' }}
+  RELEASE_TOOLS_VERSION: ${{ vars.RELEASE_TOOLS_VERSION || '0.13' }}
+

</code_context>
<issue_to_address>
**suggestion:** Avoid duplicating the default release tools version in multiple places to prevent future drift.

The default `RELEASE_TOOLS_VERSION` (`0.13`) is hard-coded both in the GitHub Actions env (`vars.RELEASE_TOOLS_VERSION || '0.13'`) and in `release-notes.sh` (`${RELEASE_TOOLS_VERSION:-"0.13"}`). Consider having a single source of truth (e.g., default only in the workflow or only in the script) and let the other inherit the value to avoid future drift.

Suggested implementation:

```
env:
  RELEASE_TOOLS_VERSION: ${{ vars.RELEASE_TOOLS_VERSION }}

```

No other workflow changes are strictly required, assuming `release-notes.sh` already defines `RELEASE_TOOLS_VERSION` with a default using `${RELEASE_TOOLS_VERSION:-"0.13"}`. If that default is removed or changed in the script, this workflow will now respect that new single source of truth.
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[tdcmeehan]

Good to have this validation