Read every page of the gitlab_pipeline_schedules data source

What does this MR do and why?

data "gitlab_pipeline_schedules" sends a single GET /projects/:id/pipeline_schedules without pagination options and keeps what comes back (datasource_gitlab_pipeline_schedules.go#L176). GitLab paginates that endpoint (present paginate(schedules) in lib/api/ci/pipeline_schedules.rb) and answers 20 schedules per page when no per_page is given, so for a project with more than 20 pipeline schedules the data source returns the first 20, and nothing in the result says the list was cut short.

A project can only hold that many where GitLab allows it: a project may have 10 pipeline schedules by default, which an administrator can raise, and GitLab.com allows 50 on its paid tiers.

This MR reads the list with gitlab.ScanAndCollect, as !2904 (merged) did for the data sources that paged by hand, so the data source follows the pages until GitLab says there are none left. It also passes the request context to the call, which the old call did not. The schema does not change.

The new TestAccDataGitlabPipelineSchedules_pagination creates 21 schedules in a new project, one more than a page holds, and checks that the data source returns all 21, with the last one created, which only the second page holds, at the end of the list. The project is new, so there are no schedules to count first, and each schedule takes one API call: deleting the project at cleanup deletes them, so the test does not read each one back and delete it the way testutil.CreateScheduledPipeline does.

To get past the limit of 10, the test first raises the default plan's ci_pipeline_schedules limit to 21 through the plan limits API when it is lower, and puts the previous value back at cleanup, the way testutil.UpdateRequirePersonalAccessTokenExpirySetting does for an application setting. Because the value goes back, the test stays with the acceptance tests rather than the settings ones, which alter the instance permanently. client-go does not model that plan limit, so the test builds those requests with NewRequest, as resource_gitlab_group_integration_jira_test.go does for its read. The limit applies to the whole instance, so the test runs non-parallel, like the gitlab_system_hooks tests. Setting the limit once in scripts/healthcheck-and-setup.sh would also work; I kept it in the test so that the test does not depend on how the instance was set up.

How to verify

Against a local make testacc-up instance:

unset GITLAB_TOKEN && make testacc RUN=TestAccDataGitlabPipelineSchedules_

With the data source as it is on main, the new test fails with Attribute 'pipeline_schedules.#' expected "21", got "20". With this change the three tests pass.

What I ran (GitLab CE 19.5.0, Go 1.26.10, Terraform 1.4.0)

The acceptance tests ran against a GitLab CE 19.5.0 container set up as make testacc-up sets it up (the repository's gitlab.rb and healthcheck-and-setup.sh, with Puma held to 4 workers to fit the host's memory), with the environment make testacc sets.

The new test with the data source as it is on main (d9991a67):

=== RUN   TestAccDataGitlabPipelineSchedules_pagination
    datasource_gitlab_pipeline_schedules_test.go:191: Step 1/1 error: Check failed: Check 1/3 error: data.gitlab_pipeline_schedules.this: Attribute 'pipeline_schedules.#' expected "21", got "20"
        Check 3/3 error: data.gitlab_pipeline_schedules.this: Attribute 'pipeline_schedules.20.id' not found
--- FAIL: TestAccDataGitlabPipelineSchedules_pagination (3.09s)

This branch:

--- PASS: TestAccDataGitlabPipelineSchedules_nilOwner (64.87s)
--- PASS: TestAccDataGitlabPipelineSchedules_pagination (3.37s)
--- PASS: TestAccDataGitlabPipelineSchedules_basic (2.26s)
PASS

The instance's ci_pipeline_schedules limit read 10 before and after both runs. With -run 'TestAcc(DataGitlab|Gitlab)PipelineSchedule', the 14 data source and resource tests of pipeline schedules pass on this branch.

To check that the test pins the paging, I made two temporary changes to the data source and ran the test against each: collecting at most 20 items (ScanAndCollectN(..., 20)) fails it with the same expected "21", got "20", and dropping the pagination option from the call makes the read ask for the first page over and over until the test times out.

go mod tidy and tfplugindocs generate change no tracked file, gofmt -s -l and go vet -tags acceptance ./internal/provider/... are clean, make lint-golangci (golangci-lint 2.15.0) reports 0 issues, lint-tfprovider, lint-examples-sh, lint-examples-tf (with Terraform 1.4.0 rather than the 1.1.4 the Makefile builds) and lint-custom pass, and make test passes.

This work comes from maintaining gitlab-mcp-server, whose upstream-bugs.md records everything done on its dependencies and sibling projects.

Related merge requests

Related to !3321 (merged), which fixed the same first-page-only read in gitlab_system_hooks, and !3332 (merged), which fixed it in gitlab_project_merge_requests.