lunny/git-lfs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Need to include actions from API in custom transfer protocol

Browse Source
This commit is contained in:
Steve Streeting 2016-07-11 10:56:37 +01:00
parent 3c4d4d3486
commit 33fa57d6f6
1 changed files with 26 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/custom-transfers.md
View File

@ -137,12 +137,18 @@ For uploads the request sent from git-lfs to the transfer process will look
like this:
```json
{ "oid": "bf3e3e2af9366a3b704ae0c31de5afa64193ebabffde2091936ad2e7510bc03a", "size": 346232, "path": "/path/to/file.png" }
{ "oid": "bf3e3e2af9366a3b704ae0c31de5afa64193ebabffde2091936ad2e7510bc03a", "size": 346232, "path": "/path/to/file.png", "action": { "href": "nfs://server/path", "header": { "key": "value" } } }
```
* `oid`: the identifier of the LFS object
* `size`: the size of the LFS object
* `path`: the file which the transfer process should read the upload data from
* `action`: the "upload" action copied from the response from the batch API.
This contains "href" and "header" contents, which are named per HTTP
conventions, but can be interpreted however the custom transfer agent wishes
(this is an NFS example, but it doesn't even have to be an URL). Generally,
"href" will give the primary connection details, with "header" containing any
miscellaneous information needed.
The transfer process should post one or more [progress messages](#progress) and
then a final completion message as follows:
@ -166,11 +172,17 @@ For downloads the request sent from git-lfs to the transfer process will look
like this:
```json
{ "oid": "22ab5f63670800cc7be06dbed816012b0dc411e774754c7579467d2536a9cf3e", "size": 21245 }
{ "oid": "22ab5f63670800cc7be06dbed816012b0dc411e774754c7579467d2536a9cf3e", "size": 21245, "action": { "href": "nfs://server/path", "header": { "key": "value" } } }
```
* `oid`: the identifier of the LFS object
* `size`: the size of the LFS object
* `action`: the "download" action copied from the response from the batch API.
This contains "href" and "header" contents, which are named per HTTP
conventions, but can be interpreted however the custom transfer agent wishes
(this is an NFS example, but it doesn't even have to be an URL). Generally,
"href" will give the primary connection details, with "header" containing any
miscellaneous information needed.
Note there is no file path included in the download request; the transfer
process should create a file itself and return the path in the final response
@ -234,6 +246,18 @@ Any unexpected fatal errors in the transfer process (not errors specific to a
transfer request) should set the exit code to non-zero and print information to
stderr. Otherwise the exit code should be 0 even if some transfers failed.
## A Note On Verify Actions
You may have noticed that that only the "upload" and "download" actions are
passed to the custom transfer agent for processing, what about the "verify"
action, if the API returns one?
Custom transfer agents do not handle the verification process, only the
upload and download of content. The verify link is typically used to notify
a system *other* than the actual content store after an upload was completed,
therefore it makes more sense for that to be handled via the normal API process.