Heidi Berry authored Sep 16, 2025 and Patrick Rice committed Sep 16, 2025

Changelog: Improvements

ci(no-release): remove dependency proxy from pipeline

See merge request gitlab-org/api/client-go!2468

chore(deps): update node docker tag to v24

See merge request !2469

Add support for the "inputs" parameter when creating pipelines via the GitLab
API. Pipeline inputs allow passing typed parameters to pipelines that use the
`spec:inputs` keyword in their `.gitlab-ci.yml` configuration.

Implementation details:
- Add PipelineInputOptions type as a map[string]any to hold input values
- Implement custom MarshalJSON to validate input types at serialization time
- Support the following value types as per GitLab API requirements:
  * string
  * integers (int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64)
  * floats (float32, float64)
  * bool
  * string slice ([]string)
- Return `ErrInvalidPipelineInputType` for unsupported types to fail fast and
  provide clear error messages

Testing improvements:
- Refactor `TestCreatePipeline` to use table-driven tests
- Add test coverage for the existing "variables" parameter
- Add test cases for pipeline inputs with various data types
- Add test case for invalid input type error handling
- Verify correct JSON serialization of both variables and inputs

This enables users to trigger pipelines with inputs like:

```go
client.Pipelines.CreatePipeline(projectID, &CreatePipelineOptions{
  Ref: Ptr("main"),
  Inputs: PipelineInputOptions{
    "environment": "production",
    "replicas": 3,
    "enable_debug": false,
    "regions": []string{"us-east", "eu-west"},
  },
})
```

Issue: gitlab-org/api/client-go#2154

Extend `RunPipelineTrigger` to support the "inputs" parameter, enabling trigger
tokens to start pipelines with typed input parameters. This mirrors the
functionality added to `CreatePipeline`, providing consistent input handling
across both pipeline creation methods.

Implementation details:
- Add Inputs field to `RunPipelineTriggerOptions` using the
  `PipelineInputOptions` type
- Reuse the same type validation and JSON marshaling logic from
  `CreatePipeline`
- Both variables and inputs can be used simultaneously, serving different
  purposes:
  * variables: simple string key-value pairs for CI/CD variables
  * inputs: typed parameters for pipelines using spec:inputs keyword

Testing improvements:
- Refactor `TestRunPipelineTrigger` to use table-driven tests
- Add comprehensive test coverage for the existing "variables" parameter
- Add test cases for pipeline inputs with various data types:
  strings, integers, booleans, and string arrays
- Add test case for invalid input type error handling

This enables trigger-based pipeline starts with typed inputs:

```go
client.PipelineTriggers.RunPipelineTrigger(projectID, &RunPipelineTriggerOptions{
  Token: Ptr("trigger-token"),
  Ref:   Ptr("main"),
  Variables: map[string]string{
    "DEPLOY_ENV": "prod",
  },
  Inputs: PipelineInputOptions{
    "environment": "production",
    "replicas": 3,
    "enable_debug": false,
    "regions": []string{"us-east", "eu-west"},
  },
})
```

Issue: gitlab-org/api/client-go#2154

Implement strongly-typed pipeline inputs for `CreatePipeline` and
`RunPipelineTrigger` using generics to ensure compile-time type safety. This
approach prevents invalid input types from being used at compile time rather
than failing at runtime.

Implementation details:
- Add `PipelineInputsOption` type to represent pipeline input parameters
- Create `PipelineInputValue[T]` generic wrapper with type constraints
- Use `PipelineInputValueInterface` to enable map storage while maintaining
  type safety
- Constrain valid types using `PipelineInputValueType` (string, integers,
  floats, bool, string slice)
- Provide `NewPipelineInputValue()` constructor following the `Ptr()` pattern

Key design benefits:
- Compile-time type validation eliminates runtime type errors
- Invalid types (e.g., `struct{}`, `map`) cannot compile
- Explicit API contract through type constraints
- Consistent with existing patterns (similar to `Ptr()` usage)
- Self-documenting through IDE autocomplete and type hints

Usage example:

```go
client.Pipelines.CreatePipeline(projectID, &CreatePipelineOptions{
  Ref: Ptr("main"),
  Inputs: PipelineInputsOption{
    "environment": NewPipelineInputValue("production"),
    "replicas":    NewPipelineInputValue(3),
    "debug":       NewPipelineInputValue(false),
    "regions":     NewPipelineInputValue([]string{"us-east", "eu-west"}),
  },
})
```

Testing:
- Update tests to use `NewPipelineInputValue()` wrapper
- Verify compile-time type checking prevents invalid types
- Maintain comprehensive coverage for all supported types
- Test both `CreatePipeline` and `RunPipelineTrigger` endpoints

Fixes: #2154

feat(PipelinesService): add support for pipeline inputs to `CreatePipeline` and `RunPipelineTrigger`

Closes #2154

See merge request gitlab-org/api/client-go!2471

# [0.146.0](v0.145.0...v0.146.0) (2025-09-18)

### Features

* **pipelines:** Add compile-time type-safe pipeline inputs support ([4b30e602](4b30e602)), closes [#2154](#2154)
* **PipelinesService:** Add support for pipeline inputs with type validation ([ab3056f4](ab3056f4)), closes [#2154](#2154)
* **PipelineTriggersService:** Add support for pipeline inputs to trigger API ([9ad770e4](9ad770e4)), closes [#2154](#2154)