Add campaign CRUD client methods and check management

[jamescarr]

Closes #612

Add full campaign lifecycle management to the Go SDK via GraphQL.

Problem

The OpsLevel GraphQL API exposes full campaign mutation support (campaignCreate, campaignUpdate, campaignDelete, campaignScheduleUpdate, campaignUnschedule, campaignEnd) plus checksCopyToCampaign for associating checks, but the Go SDK only has a ListCampaigns query. There are no client methods for creating, reading, updating, deleting, scheduling, or managing campaign checks — which blocks the Terraform provider from managing campaigns as code.

Solution

Input types (input.go):

Added GraphQL input structs matching the API schema:

• CampaignCreateInput — name, ownerId, filterId, projectBrief, checkIdsToCopy, reminder
• CampaignUpdateInput — id + optional fields for name, ownerId, filterId, projectBrief, reminder
• CampaignScheduleUpdateInput — id, startDate, targetDate
• CampaignEndInput — id, checksToPromote
• CampaignUnscheduleInput — id
• CampaignReminderInput — frequency, frequencyUnit, timeOfDay, timezone, channels, message, daysOfWeek, defaultSlackChannel
• ChecksCopyToCampaignInput — campaignId, checkIds

Payload types (payload.go):

Added response types for each mutation: CampaignCreatePayload,
CampaignUpdatePayload, CampaignDeletePayload,
CampaignScheduleUpdatePayload, CampaignUnschedulePayload,
CampaignEndPayload, ChecksCopyToCampaignPayload.

Client methods (campaign.go):

Method	GraphQL Operation	Description
GetCampaign(id)	account.campaign(id:)	Read a single campaign by ID
CreateCampaign(input)	campaignCreate	Create a draft campaign
UpdateCampaign(input)	campaignUpdate	Update campaign fields
DeleteCampaign(id)	campaignDelete	Delete a campaign
ScheduleCampaign(input)	campaignScheduleUpdate	Set start and target dates
UnscheduleCampaign(id)	campaignUnschedule	Revert to draft
EndCampaign(input)	campaignEnd	End campaign, optionally promote checks
CopyChecksToCampaign(input)	checksCopyToCampaign	Copy rubric checks into a campaign
ListCampaignChecks(id)	account.campaign.checks	List checks belonging to a campaign (paginated)

All methods follow the existing SDK patterns (client.Mutate / client.Query + HandleErrors). GetCampaign uses the account { campaign(id: $id) } query path discovered via schema introspection.

Tests (campaign_test.go):

Full test coverage for all new methods including edge cases:

• CRUD operations (create, get, update, delete)
• Schedule/unschedule lifecycle
• CopyChecksToCampaign
• ListCampaignChecks (with results and empty campaign)

Checklist

• I have run this code, and it appears to resolve the stated issue.
• This PR does not reduce total test coverage

[jamescarr]

Alright, tested a full path of create, update and delete.

  required_providers {
    opslevel = {
      source  = "jamescarr/opslevel"
      version = "1.10.9"
    }

resource "opslevel_campaign" "demo_may_rollout" {
  name      = "June 2026 Demo Checks Rollout (Revised)"
  owner_id  = data.opslevel_team.staff.id
  filter_id = data.opslevel_filter.tier1.id

  start_date  = "2026-06-15"
  target_date = "2026-08-15"

  check_ids = [
    opslevel_check_manual.demo_secret_rotation.id,
    opslevel_check_manual.demo_dependency_scanning.id,
    opslevel_check_manual.demo_error_budget.id,
  ]

  project_brief = <<-EOT
    ## Overview

    Three checks are being enabled on **June 15, 2026** as part of the
    revised sandbox demo rollout. All Tier 1 services must pass by **August 15, 2026**.

    ## Checks Included

    | Check | Category | What it verifies |
    |-------|----------|-----------------|
    | DEMO-001 | Security | Secrets rotated every 90 days |
    | DEMO-002 | Security | Dependency vulnerability scanning |
    | DEMO-003 | Reliability | Error budget defined and tracked |

    ## What you need to do

    1. Review each check's notes for pass criteria
    2. Implement any missing requirements
    3. Mark manual checks as passing with a comment explaining evidence

    ## Resources

    - [OpsLevel Checks as Code](https://engineering.index/guides/architecture/opslevel-checks/)
    - Questions? Reach out in #service-opslevel
  EOT
}

Opslevel Output

[saditya370]

@andrewstillv15
Reviewed end-to-end against a live OpsLevel localdev. Found one P0 bug, plus a few smaller items. Provider-side review with the rest is on OpsLevel/terraform-provider-opslevel#643.

🔴 P0 — UnscheduleCampaign sends the wrong GraphQL input type

UnscheduleCampaign passes DeleteInput{Id: id} but the API expects CampaignUnscheduleInput!. Mock fixtures don't validate input types, so this passed CI but breaks against the live API:

Message: Type mismatch on variable $input and argument input (DeleteInput! / CampaignUnscheduleInput!), Extensions: map[code:variableMismatch typeName:DeleteInput! variableName:input], Path: [mutation CampaignUnschedule campaignUnschedule input]

Patch:

// input.go — add new type
+// CampaignUnscheduleInput Specifies the input fields used to unschedule a campaign
+type CampaignUnscheduleInput struct {
+    Id ID `json:"id" yaml:"id" example:"Z2lkOi8vc2VydmljZS8xMjM0NTY3ODk"`
+}

// campaign.go ~ line 102
-    "input": DeleteInput{Id: id},
+    "input": CampaignUnscheduleInput{Id: id},

With this patch, the remote campaign test (6 lifecycle scenarios) goes 6/6 green.

🟡 Rebase required

Branch is based off v2026.3.6; main is now v2026.4.13 with #610 (SystemRelationship). No file conflicts expected.

🟡 gofumpt formatting

campaign.go, input.go, payload.go, campaign_test.go fail gofumpt -d. Run gofumpt -w before merge.

🟢 Worth noting

SDK mock fixtures don't validate GraphQL input types, only operation names + variable shapes.Need to strengthening fixtures or adding a live-API smoke test — this bug class will recur.