Closed ItamarMM closed 6 months ago
Thanks for raising this bug. I was able to reproduce this locally. I have a feeling this may be related to how .zip archives are created on Windows, and it would explain why all the official Dynatrace ones are fine (our pipeline packages & signs extensions on a Linux OS).
I'll have to look into this and see what solutions are there. Will be updating here and closing this issue once a fix is available.
Oh, actually. I have to take it back, this is not an issue with our VSCode extension, but with the Dynatrace API.
You can verify this by following the steps:
Environment V2
API, Extensions 2.0
endpoint
{tenant_url}/rest-api-doc/index.jsp?urls.primaryName=Environment%20API%20v2#/Extensions%202.0/extensionDetails
GET
call to the /extensions/{extensionName}/{extensionVersion}
endpoint by providing these details then clicking "Execute":
application/octet-stream
I'm sorry to pass you around, but please open a Support Ticket with Dynatrace, and feel free to reference this comment for them to have a set of reproducible steps.
Here's the Swagger API page for reference:
As this issue is reproducible outside of VSCode, just with the Dynatrace API alone, I will close this issue as it should be handled via Official Dynatrace Support.
I've reopened this issue after findings from Dynatrace Support & R&D. To summarize:
While uploading the extension ZIP file using the multipart/form-data
content type, a small part of the HTTP request is added at the beginning and the end of a file.
Extensions should be uploaded using application/octet-stream
content type instead.
I've reopened this issue after findings from Dynatrace Support & R&D. To summarize:
While uploading the extension ZIP file using the
multipart/form-data
content type, a small part of the HTTP request is added at the beginning and the end of a file.
- All extension Framework components ignore these additional parts, so the extension works.
- Command line tools (like unzip) ignore those parts and work.
- Windows can't handle that kind of “modified” file.
Extensions should be uploaded using
application/octet-stream
content type instead.
So, just to be clear, with this info I can do my job, but it really wouldn't be practical since I should still use the API manually to download the extension, modify the binary file that is in format removing the headers and footer to convert it from a multipart/form-data zip to a application/octet-stream one I guess, and then I should change the yaml in a workspace, build & upload the modified extension.
And to fix this, the problem is with the uploading part of the extension, right? So, it is a Dynatrace Extensions VS Code problem, and there is no need to contact support directly.
@ItamarMM - this was just a comment to re-open the issue, not an advice to use a different upload method.
Not to worry, it will be solved on our side in the VSCode extension, I aim to get it done by end of this week. No need for any additional support interaction.
Description
I was told by the Dynatrace Support to open an issue here.
I am having trouble initializing a workspace with an already created 2.0 extension by one of your assessors. Using the latest schema foundable in our dynatrace tenant, I am able to download other extensions, but NOT custom ones. I need to be able to edit these working custom extensions.
Let me share with you the logs:
Steps to reproduce
Support information