CODEWITHSUNDEEP
artifactorypypi
Rafael Almeida
Rafael Almeida

Reputation: 2397

Extending artifactory's pypi repos with plugins

I am trying to migrate a legacy system to use artifactory. However I have two blockers:

  1. the old scripts require PyPixmlrpc, which artifactory doesn't support
  2. they also make use of upload_docs, not supported by artifactory's pypi implementation either
  3. a smaller issue, the old scripts call register and they expect 200 instead of 204 http status code.

Would it be possible for me to write a plugin to implement this?

Looking at https://www.jfrog.com/confluence/display/RTF/User+Plugins I couldn't find a callback for when POST /api/pypi/<index-name> is requested.

If I can make

  1. work for the methods we actually use,
  2. to just pretend it deployed docs and
  3. to respond with the correct status code
I will be happy enough.

Upvotes: 4

Views: 135

Answers (1)

DarthFennec
DarthFennec

Reputation: 2778

As you say, there is no plugin hook for the Pypi API endpoints. It would be possible to use the altResponse endpoint to customize artifact downloads, but then you would be restricted to GET requests with no request body, which is also not a good option for you.

I think the most viable approach would be to define a custom executions endpoint. With this, you can specify the acceptable method, read the body, and set your own response code and body. The main shortcoming with this is that you can't customize the path (it's always /api/plugins/execute/[execution_name]), but this can be worked around.

Execution endpoints can take params in the following form:

/api/plugins/execute/[execution_name]?params=[param_name]=[param_val]

Say your plugin takes a param path, which represents the API path your old scripts are going to call. Then you can set your base URL to /api/plugins/execute/[execution_name]?params=path=/, so that the API path is appended to the param. Alternatively, you can use nginx or another reverse proxy to rewrite the original API path to this form.

(Since you'll be using XML-RPC, I don't suppose you'll need to worry about any of this path stuff, but I'm including it anyway for completeness.)

Some issues with this approach:

  • Execution endpoints only allow String responses, so sending binary data in the response body might be finnicky. However, no such limitation exists with the request body.
  • If you need more than one request method, you'll need more than one execution endpoint. This means you'll need to use a reverse proxy to rewrite each method to a separate endpoint. Again, since XML-RPC just uses POST, this probably won't be an issue for you.
  • Execution endpoints can't customize response headers. Therefore, if your scripts expect a particular Content-Type or other header, you'll need to use a reverse proxy to insert it into the response.

Upvotes: 2

Related Questions