Motivation
Publishing PDFs (e.g. generated report one-pagers) to a Confluence page needs the file uploaded as a page attachment. There is currently no jr path to attach a binary file to a Confluence page:
jr api -d @file reads the file with std::fs::read_to_string (src/cli/api.rs:107) — UTF-8 only. A PDF's bytes are not valid UTF-8, so jr api cannot even read a binary body, let alone send multipart/form-data (it fails with stream did not contain valid UTF-8).- The native multipart uploader added for Jira attachments (
jr issue attachment upload, src/cli/issue/attachments.rs) is hard-wired to the Jira /rest/api/3/issue/{key}/attachments endpoint — it isn't reachable for the Confluence /wiki/.../child/attachment endpoint.
The net effect is that a workflow that is otherwise fully jr-native (create/update the page body via jr api PUT) has to fall back to a link-only page and host the binary elsewhere, because the one binary-upload step has no jr path.
Current workaround
Build the page as a link index (each row links out to wherever the PDF is already hosted) via a jr api PUT of the page body. The binary is never attached to the Confluence page.
Proposed feature
Extend the jr wiki tree (#581) with a Confluence attachment upload:
jr wiki attachment upload <PAGE_ID> <FILE>...
A multipart/form-data POST to /wiki/rest/api/content/{id}/child/attachment (v1) or the v2 equivalent, with header X-Atlassian-Token: nocheck, reusing the existing Jira-attachment multipart machinery generalized off the Jira-issue endpoint.
Optionally, also give jr api two lower-level primitives that would unblock arbitrary binary Atlassian uploads generically:
--data-binary @file — send raw bytes with no UTF-8 decode (fixes the read_to_string limitation above).--form field=@file — a multipart/form-data mode.
Related
Motivation
Publishing PDFs (e.g. generated report one-pagers) to a Confluence page needs the file uploaded as a page attachment. There is currently no
jrpath to attach a binary file to a Confluence page:jr api -d @filereads the file withstd::fs::read_to_string(src/cli/api.rs:107) — UTF-8 only. A PDF's bytes are not valid UTF-8, sojr apicannot even read a binary body, let alone sendmultipart/form-data(it fails withstream did not contain valid UTF-8).jr issue attachment upload,src/cli/issue/attachments.rs) is hard-wired to the Jira/rest/api/3/issue/{key}/attachmentsendpoint — it isn't reachable for the Confluence/wiki/.../child/attachmentendpoint.The net effect is that a workflow that is otherwise fully
jr-native (create/update the page body viajr apiPUT) has to fall back to a link-only page and host the binary elsewhere, because the one binary-upload step has nojrpath.Current workaround
Build the page as a link index (each row links out to wherever the PDF is already hosted) via a
jr apiPUT of the page body. The binary is never attached to the Confluence page.Proposed feature
Extend the
jr wikitree (#581) with a Confluence attachment upload:A
multipart/form-dataPOST to/wiki/rest/api/content/{id}/child/attachment(v1) or the v2 equivalent, with headerX-Atlassian-Token: nocheck, reusing the existing Jira-attachment multipart machinery generalized off the Jira-issue endpoint.Optionally, also give
jr apitwo lower-level primitives that would unblock arbitrary binary Atlassian uploads generically:--data-binary @file— send raw bytes with no UTF-8 decode (fixes theread_to_stringlimitation above).--form field=@file— amultipart/form-datamode.Related
jr wiki {page, space, comment}subcommand tree for Confluence #581 —jr wiki {page, space, comment}subcommand tree. This is the attachment leg of that tree.jr issue attachment {list,download,upload,delete}tree — the multipart upload machinery to generalize.