Skip to content

Comments

feat: add external CLI support for image upload/delete#481

Open
minodisk wants to merge 1 commit intok1LoW:mainfrom
minodisk:main
Open

feat: add external CLI support for image upload/delete#481
minodisk wants to merge 1 commit intok1LoW:mainfrom
minodisk:main

Conversation

@minodisk
Copy link

@minodisk minodisk commented Jan 2, 2026 •
edited
Loading

Summary

  • Add support for external CLI commands for image upload and delete operations via -u and -d flags
  • Introduce Storage interface to abstract image storage (Google Drive vs external CLI)
  • Support template variables ({{mime}}, {{id}}, {{env.XXX}}) in upload/delete commands
  • Environment variables DECK_UPLOAD_MIME and DECK_DELETE_ID are passed to external commands

Motivation

This provides a workaround for #372.

In restricted Google Workspace environments where public file sharing is prohibited, Google Drive cannot be used for image storage. This feature allows users to use alternative storage backends (e.g., GCS, S3) via external CLI tools.

Usage

deck apply -u "my-uploader upload --mime {{mime}}" -d "my-uploader delete --id {{id}}" slides.md

External CLI Protocol

Upload command:

  • Receives image data via stdin
  • Environment variable DECK_UPLOAD_MIME contains the MIME type
  • Template variable {{mime}} is also available
  • Must output: public URL (line 1) and uploaded ID (line 2)

Delete command:

  • Environment variable DECK_DELETE_ID contains the uploaded ID
  • Template variable {{id}} is also available

Example Implementation

reprint - A GCS-based image storage CLI that implements this protocol

deck apply -u "reprint-gcs upload --mime {{mime}}" -d "reprint-gcs delete --object-id {{id}}" slides.md

Test plan

  • Tested with external storage CLI (reprint-gcs → GCS)
  • Tested with Google Drive storage (default behavior)
  • Verified both storage paths work correctly

🤖 Generated with Claude Code

@minodisk
Add external storage CLI support (#2)
4b3439c 
## Summary
- Add `-u` (`--image-upload-command`) and `-d` (`--image-delete-command`) flags to the `apply` command
- Enable using external CLI tools for image upload and deletion instead of Google Drive
- Allows integration with custom storage backends (GCS, S3, etc.) via CLI wrappers
- Introduce `Storage` interface for consistent architecture

## Architecture
- `Storage` interface with `Upload()` and `Delete()` methods
- `googleDriveStorage`: default implementation using Google Drive
- `externalStorage`: implementation using external CLI commands

## CLI Specification

### Upload Command
The upload command receives:
- **stdin**: image binary data
- **Environment variable**: `DECK_UPLOAD_MIME` (MIME type of the image)
- **Template variable**: `{{mime}}`, `{{env.XXX}}`

Expected output (stdout):
```
<public URL>
<uploaded ID for deletion>
```

### Delete Command
The delete command receives:
- **Environment variable**: `DECK_DELETE_ID` (uploaded ID to delete)
- **Template variable**: `{{id}}`, `{{env.XXX}}`

## Example Usage
```bash
deck apply -i PRESENTATION_ID \
  -u "reprint-gcs upload" \
  -d "reprint-gcs delete" \
  slides.md
```

## Test plan
- [x] Verify build passes
- [x] Verify existing Google Drive upload still works when no external CLI is specified
- [x] Test with reprint-gcs
@Songmu
Copy link
Collaborator

Songmu commented Jan 3, 2026

This is a good idea and a challenge we want to solve.
It's a clean design, but we need to discuss whether introducing this complexity is necessary and whether this protocol is the right approach.

@minodisk
Copy link
Author

minodisk commented Jan 3, 2026

Thank you for the feedback!

On Complexity

The design intentionally keeps the default behavior unchanged — users who can use Google Drive don't need any additional configuration. The complexity only applies to users like me who face Google Workspace organizational restrictions and cannot attach images via Google Drive.

I also tried implementing GCS support directly inside deck, but it felt unclean to embed specific storage implementations. Delegating to external CLI keeps deck's core simple and allows users to choose their preferred storage backend.

On Protocol

For the input side, I referenced laminate's protocol — thank you for that elegant design!

For the output (which returns 2 values: public URL and uploaded ID), I went with a simple line-based format, but I'm honestly uncertain about this choice and thinking JSON might be better for extensibility. I'd appreciate any feedback on the protocol as a whole if you have suggestions for a better approach.

@github-actions

This comment has been minimized.

Sign in to view
@github-actions

This comment has been minimized.

Sign in to view
This was referenced Jan 11, 2026
Merged
Closed
@github-actions

This comment has been minimized.

Sign in to view
@Songmu
Copy link
Collaborator

Songmu commented Jan 13, 2026

  • It's great that you haven't changed the default behavior.
    • Also, I think the design of covering multiple implementations through a command-line tool, rather than adding each one individually, is excellent as it keeps things to a necessary minimum.

  • Regarding the protocol, using standard I/O makes perfect sense.

    • However, as you mentioned, the output format needs further consideration.
    • Having the information split into two lines is confusing; if it's a single set of information, it would be better to keep it on one line.
    • As per your suggestion, I think converting it to JSON would also be a good idea.

  • While I understand that this mechanism is a desirable feature, I felt it might be difficult to grasp without a sample command.

    • It might be better to create a location like contrib/ for that purpose (though it doesn't exist yet).

@github-actions

This comment has been minimized.

Sign in to view
@github-actions

This comment has been minimized.

Sign in to view
@github-actions
Copy link
Contributor

github-actions bot commented Jan 19, 2026

Code Metrics Report

main (617ad0b) main (d7be869) +/-
Coverage 33.8% 33.8% 0.0%
Code to Test Ratio 1:0.9 1:0.9 0.0
Test Execution Time 10s 10s 0s
Details 
  |                     | main (617ad0b) | main (d7be869) | +/-  |
  |---------------------|----------------|----------------|------|
  | Coverage            |          33.8% |          33.8% | 0.0% |
  |   Files             |             31 |             31 |    0 |
  |   Lines             |           3405 |           3405 |    0 |
  |   Covered           |           1151 |           1151 |    0 |
  | Code to Test Ratio  |          1:0.9 |          1:0.9 |  0.0 |
  |   Code              |           7020 |           7020 |    0 |
  |   Test              |           6581 |           6581 |    0 |
  | Test Execution Time |            10s |            10s |   0s |

Code coverage of files in pull request scope (42.8% → 42.8%)

Files Coverage +/- Status
cmd/apply.go 19.4% 0.0% modified
deck.go 11.6% 0.0% modified
md/cel.go 45.5% 0.0% modified
md/md.go 79.2% 0.0% modified
preload.go 0.0% 0.0% modified

Reported by octocov

This was referenced Jan 21, 2026
Closed
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@minodisk @Songmu