Skip to content

Conversation

@krehermann
Copy link
Contributor

Requires

Supports

Implements M1 milestone for loading job specifications from TOML configuration at node startup.

Features:
- LoadJobsFromConfig with dependency injection pattern
- ParseJobSpecsFromTOML for [[Jobs]] section parsing
- Idempotent loading via ExternalJobID
- Comprehensive test coverage (10 tests)
- Success/failure observability

Breaks import cycles using ValidatorFunc injection.
Backward compatible with existing job loading.
- Add ConfigTOMLPath to ApplicationOpts
- Add job loading after jobSpawner creation
- Support cron and directrequest validators
- Build verified
Changed integration to use correct job format:
- type="standardcapabilities" with command field (cron, consensus, streams)
- Not separate types like type="cron", type="directrequest"

Updates:
- application.go: Changed validators map to use standardcapabilities key
- loader_test.go: Updated all tests to use standardcapabilities format

This aligns with the actual job architecture where all standard
capabilities jobs use the same type with different command values.
Changed job loading to use cfg.ConfigTOML() which returns the
effective merged configuration from all TOML files, rather than
trying to read a specific file path. This properly supports the
CLP operator's config layering where multiple configs are passed
via -c flags and merged.

- Removed ConfigTOMLPath field from ApplicationOpts
- Read from effective config using cfg.ConfigTOML()
- Works with any config source (file, env, CLP ConfigMaps)
M1 reads from the effective configuration which is the merged result of all
TOML files passed via -c flags. No hardcoded paths needed.

For K8s/CLP deployments, job config should be added to ConfigMaps with
descriptive keys (e.g., standardcap-jobs.toml) which the operator will
automatically mount and include in the -c flags.
@github-actions
Copy link
Contributor

github-actions bot commented Feb 2, 2026

I see you updated files related to core. Please run pnpm changeset in the root directory to add a changeset as well as in the text include at least one of the following tags:

  • #added For any new functionality added.
  • #breaking_change For any functionality that requires manual action for the node to boot.
  • #bugfix For bug fixes.
  • #changed For any change to the existing functionality.
  • #db_update For any feature that introduces updates to database schema.
  • #deprecation_notice For any upcoming deprecation functionality.
  • #internal For changesets that need to be excluded from the final changelog.
  • #nops For any feature that is NOP facing and needs to be in the official Release Notes for the release.
  • #removed For any functionality/config that is removed.
  • #updated For any functionality that is updated.
  • #wip For any change that is not ready yet and external communication about it should be held off till it is feature complete.

@cl-sonarqube-production
Copy link

Quality Gate failed Quality Gate failed

Failed conditions
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarQube

Catch issues before they fail your Quality Gate with our IDE extension SonarQube IDE SonarQube IDE

@trunk-io
Copy link

trunk-io bot commented Feb 2, 2026

Static BadgeStatic BadgeStatic BadgeStatic Badge

Failed Test Failure Summary Logs
Test_CRE_V2_EVM_WriteReport_Failing_On_Receiver/[v2]_EVM.WriteReport_-_failing_on_receiver_fails_with_tx_status_set_to_revert_o... The test failed during an EVM write regression due to a revert error on the receiver contract. Logs ↗︎
Test_CRE_V2_EVM_WriteReport_Failing_On_Receiver The test named 'Test_CRE_V2_EVM_WriteReport_Failing_On_Receiver' failed during execution. Logs ↗︎

View Full Report ↗︎Docs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant