I tried doing the following on our system and managed to break everything
curl octopus/api/projects/projects-98/variables/49c6c06e-54ea-4bdb-a7da-a4596e9ef3ab -XPUT -d
What I get back is a 200 OK with the Name, Value, Environment and StepId set to null.
I try and log into octopus and fix the issue and everything is broken. Upon querying the api it spits out a json parse error.
To fix it I had to go into raven and change the data manually.
Okay so the question is …
How can I set a project variable using the REST API?
First, you would need to do a ‘POST’ rather than a ‘PUT’ to add a variable. If you want to update an existing variable, you would have to list them, then work out the one to change, and then do a PUT including the
Id of the variable (the GUID) to update. This is because a variable can be defined multiple times with different scopes.
I think you’ll also need to include the
Content-type: application/json header in your request so that our model binder knows you are sending JSON. Currently it seems to be ignoring the content.
Hope that helps,
Hey Paul thanks it was essentially the content-type causing problems (I’d specified it incorrectly in the client I was using).
And yes I was trying to update an existing variable, I should have been clearer in my question.
Some feedback and opinions on behavior I didn’t expect, no doubt there in your back log but I hope you don’t mind me giving my pennies worth.
If I’m trying to update the value only, when providing the payload
In my option no other values should change other than “value” rather than setting the entire resource. As a side if you don’t specify name it get’s set to null and causes everything to break with parse errors. If its required put some validation on it and let me know if I fail to meet it.
Perhaps it’s more of an ideological vs practical argument. Should I have to specify the complete resource when trying to set it? Maybe I should but if I did it would be nice to get some hints about the ones that I do, even if I have to explicitly set them to null, something like this perhapps?
Then anything else just returns a validation error.
For 2.0 we’re working on some changes to the API, and this will include more documentation and better validation for activities like this. You’ll get validation errors when required fields aren’t provided, and there will be some metadata available to describe the fields that can be changed from the API.
Currently the API exists alongside the website, so it doesn’t get a lot of love. For 2.0 we’ll actually be making the API the primary way of interacting with Octopus, and the web portal will be rewritten so that it works solely through the API.
(That said, I’m not sure if we’ll support a patching API like you describe, it’s likely that we’ll still expect the full resource to be PUT back)