Release v10.11.15

[asjohnston-asf]

@cmarshak any concerns with releasing Thursday morning? This will make the new transformer_v0_32 and transformer_v1_32 options available in hyp3-tibet-jpl and hyp3-nisar-jpl.

---

Verification job https://hyp3-test-api.asf.alaska.edu/jobs/4892b87a-4634-4fdd-b66b-b5251df67faf ran with no issues.

TODO

• disable hyp3-edc-prod cluster and let desired vcpus drop below 1,200 before merging so the deployment will succeed

To fix this issue, an explicit permissions block should be added to the workflow. This block can be placed at the workflow root (applying to all jobs, including the called reusable workflow), or inside the specific job definition. Since the code only shows a single job (using a reusable workflow), placing the permissions block at the root is the cleanest approach and matches GitHub documentation and recommendations.

The most restrictive and generally safe starting point is:

permissions:
  contents: read

If the reusable workflow needs more specific permissions (e.g., write access to pull-requests), additional lines can be added, but contents: read is the safest minimal setting for workflows that only need to check code or metadata.

Add the following near the top, below the name (line 1) and before the on: block (line 3).

To fix the problem, we need to add a permissions block to the workflow file .github/workflows/labeled-pr.yml, setting it at either the root (for all jobs) or under the relevant job (for that job only). Since the current workflow consists of a single job that calls a reusable workflow, it is most straightforward and idiomatic to place the permissions block at the workflow root.

As for which permissions to grant: unless the called reusable workflow’s documentation says otherwise, the most restrictive and safest starting point is to set contents: read. If the workflow requires other permissions (such as to comment on issues or manage pull requests, which is common for PR labeling or status check actions), these should be explicitly set. In the absence of precise requirements, a minimal starting block of contents: read is recommended, which can later be expanded as needed.

The change should be made at the top level of the YAML file, ideally after the name and before the on section for clarity.

---

[github-actions]

Developer checklist

• Indicated the level of changes to this package by affixing one of these labels:
  • major -- Major changes to the API that may break current workflows
  • minor -- Minor changes to the API that do not break current workflows
  • patch -- Patches and bugfixes for the current version that do not break current workflows
  • bumpless -- Changes to documentation, CI/CD pipelines, etc. that don't affect the software's version
• (If applicable) Updated the dependencies and indicated any downstream changes that are required
• Added/updated documentation for these changes
• Added/updated tests for these changes
• Verified changes in test deployment and summarized results, e.g. in PR description or comments on the related issue(s)
• If the step function code has changed, have you drained the job queue before merging?
  • For example, if the interface for a Lambda function has changed to expect different input,
    then currently running jobs (which use the old step function definition) will call the new
    function with the old input. So we must drain the job queue before deployment, so that the new
    function is only called by the new step function definition.

Reviewer checklist

• Have all dependencies been updated?
• Is the level of changes labeled appropriately?
• Are all the changes described appropriately in CHANGELOG.md?
• Has the documentation been adequately updated?
• Are the tests adequate?
• Have the changes been verified in the test deployment?

[cmarshak]

No concerns with me. Thanks! Super appreciate using this.