Skip to content

fix(skill): use --from/--to for openlayer export in the CLI reference - #25

Open
eastagiletracker wants to merge 1 commit into
openlayer-ai:mainfrom
eastagiletracker:agile-board/cli-export-time-range-flags
Open

fix(skill): use --from/--to for openlayer export in the CLI reference#25
eastagiletracker wants to merge 1 commit into
openlayer-ai:mainfrom
eastagiletracker:agile-board/cli-export-time-range-flags

Conversation

@eastagiletracker

Copy link
Copy Markdown

This PR proposes correcting the openlayer export time-range form in skills/openlayer/references/cli.md, which currently teaches an invocation the Openlayer CLI rejects. We include this PR work along with a full history of your repo at https://eastagiletracker.com/projects/289. You can sign in with your GitHub ID to claim ownership of the project.

What's wrong

The Core commands table documents openlayer export with the start and end times passed positionally, and the Common Mistakes table repeats that same form as the fix for getting export wrong. Positional start/end are the legacy arguments and parse as Unix timestamps only, so an agent that follows the reference to export a date range emits a command that never runs. Against CLI 1.14.0, installed with the script this same reference recommends:

$ openlayer export demo 2025-08-01 2025-08-10
Error: invalid start timestamp: strconv.ParseInt: parsing "2025-08-01": invalid syntax

Your own command page has already moved on: https://docs.openlayer.com/api-reference/cli/commands/export.md shows every date-range example with --from / --to, and lists the positional arguments separately as the legacy form with Unix timestamps. The reference kept the bare usage line without that distinction, so the one detail that decides whether the command runs is the one an agent does not have.

The change

In skills/openlayer/references/cli.md, the Core commands row now uses --from / --to and notes that --last 7d and --range this-week also work. The Common Mistakes row changes from "wrong export arg order" to the trap that actually bites — positional times are Unix-only — and gives the working command. Nothing else in the reference changed: I re-checked the rest of its command surface against 1.14.0 (push -m/-w/-t, validate, inspect, projects create, tests -o, metrics push/run/pull/delete) and the headless OPENLAYER_API_KEY + OPENLAYER_PROJECT_ID path, and all of it is accurate today.

Verification, replayable in a minute: python3 scripts/validate_skills.py passes before and after the change (frontmatter, cross-links, no orphan references, version lockstep), and the two invocations above are the before/after — the documented form fails while parsing its arguments, while openlayer export demo --from 2025-08-01 --to 2025-08-10 parses and proceeds to the authenticated call (Invalid authentication credentials, with a dummy key). Per CONTRIBUTING.md this is a content fix inside the published skill, so the three manifests are bumped 0.3.0 → 0.3.1 in lockstep in the same commit; drop that hunk if you would rather bump at release time.

How this was managed

This work was tracked as a single story on a board imported from this repository's own issues and pull requests (24 stories):

board

If you'd rather not receive contributions like this, reply no-more-prs on this pull request and we won't open any further ones on your repositories.


Lawrence W. Sinclair
CEO / East Agile
linkedin.com/in/lwsinclair/
eastagile.com

… (v0.3.1)

The Core commands table documented `openlayer export <pipelineId> <start> <end>`
and the Common Mistakes table repeated that form as the fix, so an agent asked to
export a date range emits it with dates. Positional start/end are the legacy
Unix-timestamp-only form, so CLI 1.14.0 rejects it:

  $ openlayer export my-pipeline 2025-08-01 2025-08-10
  Error: invalid start timestamp: strconv.ParseInt: parsing "2025-08-01": invalid syntax

Document the current interface (`--from`/`--to`, plus `--last` / `--range`) and
turn the mistakes row into the trap that actually bites. Patch bump across the
three plugin manifests, in lockstep.
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