Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

How to submit a different namespace to ProjectImportExport.import() ? #568

Closed
SirkoS opened this issue Jan 22, 2020 · 2 comments · Fixed by #570
Closed

How to submit a different namespace to ProjectImportExport.import() ? #568

SirkoS opened this issue Jan 22, 2020 · 2 comments · Fixed by #570

Comments

@SirkoS
Copy link
Contributor

SirkoS commented Jan 22, 2020 •
edited

From reading the Gitlab documentation on importing project from a file there are some more parameters then file ad path, that are supported here.

import(content: string, path: string, options?: Sudo) {

Using the general options is of no use, as the parameters there will be overwritten later on in the execution pipeline.

const response = await service.requester.post(service, endpoint, {
    body: form || body,
    sudo,
  });

I have have commit that fixes that over in my fork (in particular this commit). However, before I make a pull request, please check, if the implementation fits your code-style or you prefer something different.
@jdalrymple
Copy link
Owner

Hmm you actually found a pretty important edge case. To avoid solving it for just this use case, I'm going to fix up the functionality in the RequestHelper. I'll post something up in the next couple hours!

jdalrymple added a commit that referenced this issue Jan 23, 2020
@jdalrymple
fix: Adding better handling for form type arguments. This should be a…
69eb9af 
…ble to account for any form arguments passed to the requestHelper

BREAKING CHANGE: Trigger.pipeline now has a defined variables property to house all the pipeline variables to be set. Before these variables were set on the root object, but this made it difficult to parse any future options that may be added to this function.

fixes: #568
@jdalrymple jdalrymple mentioned this issue Jan 23, 2020
Merged
@jdalrymple jdalrymple added the Bug label Feb 16, 2020
jdalrymple added a commit that referenced this issue Mar 24, 2020
@jdalrymple
fix(core): Adding better handling for form type arguments
c316026 
This should be able to account for any form arguments passed to the requestHelper.

BREAKING CHANGE: Trigger.pipeline now has a defined variables property to house all the pipeline variables to be set. Before these variables were set on the root object, but this made it difficult to parse any future options that may be added to this function.

fixes: #568
jdalrymple added a commit that referenced this issue Mar 24, 2020
@jdalrymple
fix(core): Adding better handling for form type arguments
32148cf 
This should be able to account for any form arguments passed to the requestHelper.

BREAKING CHANGE: Trigger.pipeline now has a defined variables property to house all the pipeline variables to be set. Before these variables were set on the root object, but this made it difficult to parse any future options that may be added to this function.

fixes: #568
jdalrymple added a commit that referenced this issue Mar 24, 2020
@jdalrymple
fix(core): Adding better handling for form type arguments (#570)
4751ed2 
This should be able to account for any form arguments passed to the requestHelper.

BREAKING CHANGE: Trigger.pipeline now has a defined variables property to house all the pipeline variables to be set. Before these variables were set on the root object, but this made it difficult to parse any future options that may be added to this function.

fixes: #568
jdalrymple pushed a commit that referenced this issue Mar 24, 2020
@semantic-release-bot
chore: Release 🚀 17.0.0 [skip ci]
d850e8d 
# [17.0.0](16.0.0...17.0.0) (2020-03-24)

### Bug Fixes

* **core:** Adding better handling for form type arguments ([#570](#570)) ([4751ed2](4751ed2)), closes [#568](#568)

### BREAKING CHANGES

* **core:** Trigger.pipeline now has a defined variables property to house all the pipeline variables to be set. Before these variables were set on the root object, but this made it difficult to parse any future options that may be added to this function.
@jdalrymple
Copy link
Owner

🎉 This issue has been resolved in version 17.0.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix: Adding better handling for form type arguments. jdalrymple/gitbeaker
2 participants
@jdalrymple @SirkoS