Can anyone help me in getting the list of changesets or the files which are modified using oslc.
Iam using rtc ccm.
Iam able to get it through workitem, but I want to access all changesets directly from scm or any method to get the UUID for all changesets
This url used for achieving the above problem, but I'm not sure it is using OSLC concept in it.
.com/ccm/service/com.ibm.team.scm.common.internal.rest.IScmRestService2/historyPlus? n=25&path=workspaceId%2F_Dh7kMAHIEeSZzL8CZgHcOQ%2FcomponentId%2F_j7JnAbl2EeOYP5vHPrH3vA
It returns the change sets without the need of workitem.
if any one find any other (using OSLC & not using API) way please post it here
Related
i was trying to get the list of projects in my gitlab using Git api. for that i was following Git lab api instruction.
they said i can access the list of project by this link:
https://gitlab.com/api/v4/projects?access_token=some_token.
but unfortunately with the above link i got bunch of information, which is not mine at all. i got the information which is owned by other users.
In that case how am i able the get my own projects information?
Nevertheless, the respond JSON has so many attribute. is there anyway that i can achieve the attribute according to my desire?
You can use owned=true to get only project which you are owner and simple=true to have limited field, check this :
https://gitlab.com/api/v4/projects?access_token=some_token&owned=true&simple=true
I have created a atlassin account for testing the Jira rest api and created a project and tickets under it.
I am able to access the projects but not the issues under it. Please find below for more info
Could someone please help me what permissions I am missing
We can access the issues using URL request for api as below
"https://site.atlassian.net/rest/api/2/search?jql=updated>-90d&startAt="
Not a permission issue, but you missed adding issueIdOrKey path parameter. JIRA attempts to identify the issue by the issueIdOrKey path parameter. This can be an issue id, or an issue key.
To get the issue details, you can use the following Jira Rest endpoint,
GET /rest/api/2/issue/{issueIdOrKey}
For your case it will be,
GET /rest/api/2/issue/BI-1
Does anyone know how to create a branch using the VSO Api. The documentation for Branches doesn't include a "create".
I have been experimenting with doing it via the ChangeSet Api without much success.
This is TFVC, not Git.
Just as what you see in "Branches" page, there isn't any way to create branch with the Rest API. And mostly, you can only read/get the information with the Version Control API for now.
I would recommend you to use Client Object Model Reference if you want to manage the Version Control programmatically. To create a branch, use the "CreateBranch()" method in Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer class.
The REST API apparently does allow one to create branches.
The confusion is that people think that this would be a PUT operation on the Branches endpoint of some kind.
It is not.
In the REST API, a branch is just one more kind of change that is checked in as part of a changeset.
It took me a long time to discover this, myself; and I was using the old SOAP API in the belief, shared by everyone else it appears from what I can find in Q&As on the WWW, that this wasn't part of the REST API.
Of course, using the SOAP API prohibits using .NET 5, because the assemblies only come for .NET Framework.
An abandonware API on an abandonware runtime is not a satisfactory way to talk to source control. ☺
The terrible Azure DevOps documentation gives no clue as to this, except for 1 obscure not-even-a-complete-sentence hidden in a minor class: "List of merge sources in case of rename or branch creation."
The only other clue is what appears in the JSON, from a get changeset changes, that describes the changeset of an already-made branch.
The (also abandoned) Azure DevOps sample code does not contain examples for even deleting an item, let alone branching.
Changesets are checked in via the changeset creation endpoint.
The individual change is a TfvcChange in the changeset's list of changes where:
the version control type (which is a set of flags) contains the branch flag; and
the merge source for the change specifies the source item and the range of changeset numbers.
Branching an entire tree appears to be a matter of branching the directory and all of the files and directories in the directory.
In C♯ or PowerShell, this is a TfvcChange with a VersionControlChangeType of Branch, in a TfvcChangeset passed to TfvcHttpClientBase.CreateChangesetAsync().
I have the need to add a licence field to the APIs published by the API manager.
It does not seems to be any extension point beyond the api.rxt file in the resource folder.
If I modify the file and run the application the carbon app correctly show the added field, but nor the publishe nor the store are able to get the field and there is no way to get it also with REST APIs since it calls a method of a class that (in later versions) outputted fields positionally.
Is it possible to add the field, without running the risk of crashing the API Manager?
Which is the correct way?
Thanks
This change cannot be done without modifying the code. When an API is created from the Publisher app, it gets stored in the registry. The api.txt you modified, only defines the structure of this stored artifact. It may add a new field to the artifact, but to correctly populate that field, you need to modify several methods in APIProviderHostObject and APIProviderImpl + several Jaggery scripts.
I'm relatively new with Seapines SurroundSCM API, so I might just be missing something obvious. Is there a way to generate a ticket that is then sent to TestTrack whenever a file is checked in using the SurroundSCM API? I'm being told there is a way to do it, but I can't find anything in the documentation or their site.
It is not possible to perform this action from the Surround SCM API because creating a defect/ticket is a TestTrack operation. Here are two potential approaches to take.
(1) Your application can use the addDefect function in the TestTrack API to create a new defect/ticket. So your application would use the Surround SCM API to check in the file and the TestTrack API to create the defect/ticket.
(2) You could create a second application to create a new defect/ticket via the TestTrack API. This second application could be run as the result of a Surround SCM trigger event. You could configure the preconditions of the SCM trigger to be limited to a specific group of users or specific repository.