Andreas Hilbig fb5e9cbe81 feat: improve Zabbix multi-version compatibility and introduce local development environment

This update enhances compatibility across multiple Zabbix versions and introduces tools for easier local development and testing.

Key improvements and verified version support:
- Verified Zabbix version support: 6.2, 6.4, 7.0, and 7.4.
- Version-specific feature handling:
- `history.push` is enabled only for Zabbix 7.0+; older versions skip it with a clear error or notice.
- Conditional JSON-RPC authentication: the `auth` field is automatically added to the request body for versions older than 6.4.
- Implemented static Zabbix version caching in the datasource to minimize redundant API calls.
- Query optimization refinements:
- Added mapping for implied fields (e.g., `state` -> `items`, `deviceType` -> `tags`).
- Automatically prune unnecessary Zabbix parameters (like `selectItems` or `selectTags`) when not requested.
- Local development environment:
- Added a new `zabbix-local` Docker Compose profile that includes PostgreSQL, Zabbix Server, and Zabbix Web.
- Supports testing different versions by passing the `ZABBIX_VERSION` environment variable (e.g., 6.2, 6.4, 7.0, 7.4).
- Provided a sample environment file at `samples/zabbix-local.env`.
- Documentation and Roadmap:
- Updated README with a comprehensive version compatibility matrix and local environment instructions.
- Created a new guide: `docs/howtos/local_development.md`.
- Updated maintenance guides and added "Local Development Environment" as an achieved milestone in the roadmap.
- Test suite enhancements:
- Improved Smoketest and RegressionTest executors with more reliable resource cleanup and error reporting.
- Made tests version-aware to prevent failures on older Zabbix instances.

BREAKING CHANGE: Dropped Zabbix 6.0 specific workarounds; the minimum supported version is now 6.2.

2026-02-04 14:01:53 +01:00

2.4 KiB

Raw Blame History

Technical Maintenance Guide

This guide covers the technical aspects of maintaining and developing the Zabbix GraphQL API.

🛠️ Development & Maintenance Tasks

Code Generation

The project uses GraphQL Codegen to generate TypeScript types from the GraphQL schema. This ensures type safety and consistency between the schema and the implementation.

Configuration: codegen.ts
Generated Output: src/schema/generated/graphql.ts

How to Regenerate Types

Whenever you modify any .graphql files in the schema/ directory, you must regenerate the TypeScript types.

For a one-off update (e.g. in a script or before commit):

npx graphql-codegen --config codegen.ts

If you are a developer and want to watch for schema changes continuously:

npm run codegen

Testing

We use Jest for unit and integration testing.

Test Directory: src/test/
Execution:
```
npm run test
```

Local Development Setup

For running integration tests against a real Zabbix instance, it is recommended to use the Local Development Environment. This setup allows you to test the API against specific Zabbix versions (e.g. 6.4, 7.0) in an isolated way.

Adding New Tests

Location: Place new test files in src/test/ with the .test.ts extension.
Coverage: Ensure you cover both successful operations and error scenarios.
Test Specification: Every new test must be documented in the Test Specification.
Best Practice: If you find a bug, first create a reproduction test in src/test/ to verify the fix.

🔄 Updating Dependencies

To keep the project secure and up-to-date:

Check for updates: npm outdated
Update packages: npm update
Verify with tests: npm run test

🐳 Docker Image Maintenance

The Dockerfile uses a multi-stage build to keep the production image small and secure.

Base Image: Node 24 (LTS)
Build Argument: API_VERSION (used to embed the version into the image)

To build a fresh image locally:

docker build -t zabbix-graphql-api --build-arg API_VERSION=$(git describe --tags --always) .

Related Reference: Project Configuration Reference Related Cookbook: Extending the Schema

2.4 KiB Raw Blame History