Fix #6411: pass the download config to lesson_checks.yml

[Solarthis]

Explanation

Fixes #6411: lesson_checks.yml invoked //scripts:download_lesson_list with 5 arguments, but the script requires 6. Every scheduled Monday run failed at the "Download lesson version list" step with the usage error, so no lesson compatibility data was collected.

DownloadLessonList.kt asserts the arity directly:

check(args.size in 6..7) {
  "Expected use: bazel run //scripts:download_lesson_list -- <base_url> <gcs_base_url>" +
    " <gcs_bucket> </path/to/api/secret.file> </path/to/output_list.textproto>" +
    " </path/to/download_config.[textproto,pb]> [</path/to/api/debug/dir>]"
}

args[5] is downloadConfigPath, and the script checks that the file exists. The parameter arrived with pull_latest_lesson_versions.yml, which passes it correctly; lesson_checks.yml was never updated to match. This change adds the missing 6th argument, so the two callers agree.

Why prod_download_config.textproto

Two configs exist — alpha_download_config.textproto and prod_download_config.textproto. The prod one is correct here because this job is name: Check production lesson conversion and downloads from https://www.oppia.org, matching how pull_latest_lesson_versions.yml pairs the prod server with the prod config for its prod output.

Note on the path

scripts/assets/*_download_config.textproto does not exist on develop — it lives on introduce-asset-download-script. That is fine at runtime: this workflow already does actions/checkout with ref: introduce-asset-download-script (the same reason the Bazel target resolves), so the config is present in the workspace when the step runs.

Verification

I could not execute the workflow — it is schedule / workflow_dispatch only and needs PROD_SERVER_LESSON_SECRET, which I do not have. What I did check:

• the file still parses as YAML, and the step now passes exactly 6 arguments, satisfying args.size in 6..7
• the argument order matches DownloadLessonList.kt positionally (base_url, gcs_base_url, gcs_bucket, secret, output, config)
• the resulting invocation is identical in shape to the two working calls in pull_latest_lesson_versions.yml

A maintainer with the secret can confirm via workflow_dispatch rather than waiting for the Monday cron.

Essential Checklist

• The PR title starts with "Fix #bugnum: "
• The explanation section above starts with "Fixes #bugnum: "
• Any changes to scripts/assets files have their rationale included in the PR explanation. (No scripts/assets file is changed — one is referenced; rationale for which one is above.)
• The PR follows the style guide.
• The PR does not contain any unnecessary code changes from Android Studio.
• The PR is made from a branch that's not called "develop" and is up-to-date with "develop".
• The PR is assigned to the appropriate reviewers. (I am a first-time contributor and cannot set assignees on this repo — happy for a maintainer to route it, or tell me who to request.)

Disclosure of LLM Usage

Did you use AI/LLMs when working on this PR? Yes.

If yes, describe the extent AI was used: Claude (Opus) was used for the whole of this change — locating the arity mismatch by reading DownloadLessonList.kt against both workflow callers, deciding which of the two configs applies, making the one-line edit, and drafting this description. The change is a single added argument; every claim above was checked against the files in this repository rather than assumed, and the verification limits are stated explicitly.

[github-actions]

@Solarthis this PR is being marked as draft because the PR description must contain 'Fixes #' or 'Fixes part of #' for each issue the PR is changing, and each one on its own line with no other text.

[github-actions]

Coverage Report

Results

Coverage Analysis: SKIP ⏭️

This PR did not introduce any changes to Kotlin source or test files.

To learn more, visit the Oppia Android Code Coverage wiki page

[Neer-rn]

Hi @Solarthis, thanks for your interest in contributing!

It looks like this issue hasn't been assigned to you yet. Please note that you should not raise a PR for an issue before it has been assigned to you. If you would like to work on this issue, please first leave a comment on the issue explaining how you plan to resolve it. Once we review your approach and confirm that you are on the right track, we can assign the issue to you, and you can then proceed with the PR.

For now, this PR will not be reviewed. Please also go through this wiki, especially the onboarding and starter issue instructions, before starting your contribution.

[adhiamboperes]

@Solarthis, please comment on the issue to be assigned, and please look at the failures in the PR.