fix(gitlab): don't set Content-Type header when uploading release ass…

…ets (#1183)

As noted in [a comment on #1172][1], switching to the use of the native
fetch API broken uploading release assets to GitLab by hard-coding the
Content-Type header to "text/plain". The [recommended approach][2] is to
avoid setting the Content-Type header at all and let the fetch API
implementation set it so as to ensure that the correct boundary
expression is included.

Update the `request` function to only set the Content-Type header when
body is not an instance of FormData. The default behaviour is to set the
header as before.

[1]: #1172 (comment)
[2]: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest_API/Using_FormData_Objects#sending_files_using_a_formdata_object

Closes #1172

lib/plugin/gitlab/GitLab.js

@@ -165,9 +165,13 @@ class GitLab extends Release {
     const url = `${baseUrl}/${endpoint}${options.searchParams ? `?${new URLSearchParams(options.searchParams)}` : ''}`;
     const headers = {
       'user-agent': 'webpro/release-it',
-      'Content-Type': typeof options.json !== 'undefined' ? 'application/json' : 'text/plain',
       [tokenHeader]: this.token
     };
+    // When using fetch() with FormData bodies, we should not set the Content-Type header.
+    // See: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest_API/Using_FormData_Objects#sending_files_using_a_formdata_object
+    if (!(options.body instanceof FormData)) {
+      headers['Content-Type'] = typeof options.json !== 'undefined' ? 'application/json' : 'text/plain';
+    }
     const requestOptions = {
       method,
       headers,