I am trying to get data of my builds from Teamcity and place it into a dashboard I am creating. I am getting most of the data but this thing I am missing is the timestamp of the builds. I have searched alot on internet but cant find it. In teamcity I can see the timestamp of all the builds but it is not available in the timstamp.
All suggestions are appriciated.
Thanks
You don't need to make additional calls for each build, but you need to craft how you want the response returned. There's a query string parameter called fields that lets you define what you want to bring back.
e.g. to return the start and finish data in your original call you can add &fields=build(startDate,finishDate) to your original request
/httpAuth/app/rest/buildTypes/id:##BUILD_TYPE_ID##/builds?fields=build(startDate,finishDate)
This would return something like this
<builds>
<build>
<startDate>20140202T230456+0000</startDate>
<finishDate>20140202T230518+0000</finishDate>
</build>
<build>
<startDate>20140202T224912+0000</startDate>
<finishDate>20140202T224957+0000</finishDate>
</build>
</builds>
The caveat to this is that you now have to exclusively define what you want returned. So to return all the other fields and the start / finish date, add this parameter to the query string
&fields=build(id,buildTypeId,number,status,state,branchName,defaultBranch,href,webUrl,buildTypeId,startDate,finishDate)
TeamCity documentation - Full and Partial responses
Hope this helps
After you GET /app/rest/builds?locator=buildType:..., you need to get the detailed data of all the individual build runs you're interested in. That, unfortunately, means an extra REST call for every individual build.
The URL for each build will be in the form /app/rest/builds/id:21966, but don't hard-code this in your program. Instead, as you loop through all the builds (returned by your first call), take each build's href attribute and GET that.
To summarise:
* GET /app/rest/builds?locator=buildType:... once
* for each build in the returned data set, take its href and make another REST call
* for each returned build detail, the timestamps are in the following sub-elements: queuedDate, startDate, finishDate, triggered
We've tried implementing a dashboard this way before but found it unacceptably slow (too many REST calls). There is an alternative, which is to write a TC plugin (use the native OpenAPI): that will be much faster but of course it's more work.
Related
Have been working with pytest for sometime, (and really like it, I must say). I have been able to generate a self contained html with additional columns etc. What I need is either:
Have the results displayed in the order in which they are run (not Failed first as it normally appears in the self contained html output)
OR
Print the order in which the tests are run. Am using #pytest.mark.run(order=123456) in my tests.
The order is important as there are dependency tests that needs to be executed in a certain sequence.
I'am not sure about pytest, but I worked with pyhtml and had a similar problem.
I would say you shuld use a "yield" operator in the function you are calling from your pyhtml part. If you are calling the pytest function direct from your pyhtml part, you shuld be able to write a new function, that calls pytest for you.
In my project Mockito.times(1) is often used when verifying mocks:
verify(mock, times(1)).call();
This is redundant since Mockito uses implicit times(1) for verify(Object), thus the following code does exactly what the code above does:
verify(mock).call();
So I'm going to write an a structural search drive inspection to report such cases (let's say, named something like Mockito.times(1) is redundant). As I'm not an expert in IntelliJ IDEA structural search, my first attempt was:
Mockito.times(1)
Obviously, this is not a good seach template because it ignores the call-site. Let's say, I find it useful for the following code and I would not like the inspection to trigger:
VerificationMode times = Mockito.times(1);
// ^ unwanted "Mockito.times(1) is redundant"
So now I would like to define the context where I would like the inspection to trigger. Now the inspection search template becomes:
Mockito.verify($mock$, Mockito.times(1))
Great! Now code like verify(mock, times(1)).call() is reported fine (if times was statically imported from org.mockito.Mockito). But there is also one thing. Mockito.times actually comes from its VerificationModeFactory class where such verification modes are grouped, so the following line is ignored by the inspection:
verify(mockSupplier, VerificationModeFactory.times(1)).get();
My another attempt to fix this one was something like:
Mockito.verify($mock$, $times$(1))
where:
$mock$ is still a default template variable;
$times$ is a variable with Text/regexp set to times, Whole words only and Value is read are set to true, and Expression type (regexp) is set to (Times|VerificationMode) -- at least this is the way I believed it should work.
Can't make it work. Why is Times also included to the regexp? This is the real implementation of *.times(int), so, ideally, the following line should be reported too:
verify(mockSupplier, new Times(1)).get();
Of course, I could create all three inspection templates, but is it possible to create such a template using single search template and what am I missing when configuring the $times$ variable?
(I'm using IntelliJ IDEA Community Edition 2016.1.1)
Try the following search query:
Mockito.verify($mock$, $Qualifier$.times(1))
With $Qualifier$ text/regexp VerificationModeFactory|Mockito and occurrences count 0,1 (to find it when statically imported also).
To also match new Times(1) you can use the following query:
Mockito.verify($mock$, $times$)
With $times$ text/regexp .*times\s*\(\s*1\s*\) and uncheck the Case sensitive checkbox.
Can any one help me to get the list of iterations and sprints in that and workitems in that sprint using oslc or REST call
This thread reports that querying iterations might be a bit tricky:
For the purpose of obtaining iteration for specific development line. Reporting Rest I/F may helps.
https://clm.example.com:9443/ccm/rpt/repository/foundation?fields=foundation/iteration[developmentLine/name='RTC V4.0.6 Development']/(id|name|developmentLine/name)
This yields some thing like:
<iteration> <developmentline> <name> <iteration>
<developmentline><name>RTC V4.0.6 Development</name></developmentline>
<id>Sprint 2</id>
<name>Sprint 2</name>
</iteration> </name> </developmentline> </iteration>
Unfortunately, iteration belongs to development line, so we have to query developmentLine using like:
https://clm.example.com:9443/ccm/rpt/repository/foundation?fields=foundation/developmentLine/(name|projectArea/name)
For the brief introduction to reportable RestAPI, refer to this web pages.
https://jazz.net/wiki/bin/view/Main/ReportsRESTAPI
Good feature of this reports API is that we can query by name, not uuid of objects.
There
I had also this problems solved by this way. Try it.
It returns list of Open Sprints.
http://jira.address/rest/greenhopper/1.0/sprint/picker
If you want to search for closed sprints in the future, you can use the following parameter in the above call:
http://jira.address/rest/greenhopper/1.0/sprint/picker?excludeCompleted=false
I'm trying to write a query in Rally that will show me all the defects for several projects, but every time I save the query I get the message "Could not parse: Error parsing expression -- expected ")" but saw "OR" instead."
Here is the actual query:
((((Project.Name = "Project A") OR (Project.Name = "Project B")) OR (Project.Name = "Project C")) OR (Project.Name = "Project D"))
I checked Rally's so-called Help and it seems to me that everything is set up correctly, but maybe I'm missing something?
Your query syntax and parentheses groupings look fine. I tested your exact string above in a Custom Grid and it parses fine - no "Could not parse..." error. Maybe compare the exact query you are using against your sample above? Complex AND's and OR's can definitely be frustrating. If you miss a parenthesis or spaces around operators, the query engine will complain.
fyi, I just found that doing a page reload in the browser forces the changed query expression to be evaluated, whereas simply saving the modified query does not reliably re-evaluate the changed query.
The symptom I observed was that query results continued to complain about the previous query string, even though I had replaced parts of the query with different named fields, etc. This made me suspect browser caching, and when flushing cache did not help, then I did browser page reload, which worked perfectly.
So if your browser page was reloaded between when you were having the problem and later when it started working, then this might explain why.
From About link: Rally Build: master-9274 , Browser Type: firefox/19.0, rv:19.0
FYI to start, I am aware of how to properly set up an update to a lookup, and am 99% positive I've done this correctly.
I know this because When I set the workflow to automatically start when an Item is Changed, then it works perfectly. But when I simply change this setting so it will automatically start on New Item Creation, it Cancels the workflow and I get a "Coercion Failed: Unable to transform the input lookup data into the requested type." If both options are checked then it fails on creation, but simply clicking edit on the item properties, and the "Save" makes it work.
The workflow is on a Document Library and works as follows;
User selects the Work Task LookUp from a dropdown in the edit properties form after uploading, and then Saves the item (adding it to the document library). The workflow is suppose to then look at the Work Task LookUp selected, and pull the Account and Effective Date-Type lookUp ID's that Work Task item has, and sets the Document's identical fields to the same value.
Here is the code for the workflow if it helps;
If Current Item: Parent Task is not empty
If Current Item: Sub Task is not empty
Log Both are empty to workflow history list
Then Set Account to Work Tasks:Account
The Log Set Account to workflow history list
Then Set Effective Date and Type to WorkTasks: Effective Date and Type
The Log Set EffDateType to the workflow history list
This is all done in one step. I also added additional steps to test if the account and effective date type fields have been set properly, and if not to set them again. But everytime I run the workflow on change and it works, it always correctly sets these fields based upon the first Step (posted above) and the additional check logs to the history that they are not needed.
As an example, The lookUp for Integer for Tasks:Account is set to work as follows;
Date Source: Work Tasks (a list)
Field from Source: Account (a lookup)
Return Field as: Lookup ID (as Integer)
Find the List Item
Field: Title (from the Work Tasks list)
Value: Current Item: Parent Task (Which is a look up of the "Title"
Field from Work Tasks List, and is set to return the Value as a LookUp Value (As Text))
The Effective Date and Type setting is pretty much identical.
So anyone have any insight? I've tried running it as an impersonated Step, setting a workflow pause (for 1 minute), changing the lookup types incase I messed it up to start with, but ultimately the above workflow DOES work, but only when I set it to "Automatically start on the Change (edit) of an Item", NOT "Automatically start on New Item Creation" like I need to to do.
Oh yes, fyi, I am using SPServices CascadingDropDown on the Work Task and Sub Task fields of the doc Library form, but I honestly do not believe this has anything to do with my issue.
UPDATE:
I've talked with another developer, and he believes it is due to the issue that the workflow is occuring too quickly, before the item creates an ID for itself, which it needs to conduct the lookUps. He had me add another "Pause Workflow" to the very top of my workflow code (above the If conditions) and set it for 1 minute.
It then worked properly.
Downside is we want this to labeling to occur as close to item creation as possible. Because a view of the library relies on grouping based upon Account and Effective Date and Type. To add to this downer, Microsoft's Pause Workflow only allows for 1 minute or more, and then the timer used for this is often off, resulting in a pause longer than that. So far, every test is currently showing 2 minutes minimum on the pause.
A possible alternative solution for instantaniously populate the fileds is to use Javascript and SPServices to do the lookUp to the Task list to pull the account and effective date - type fields and then populate, but my Javascript is not very strong and I would need help doing this. If anyone has any suggestions, I would appreciate them.
(Answered in a question edit. Converted to a community wiki answer. See Question with no answers, but issue solved in the comments (or extended in chat) )
The OP wrote:
I don't know if it is the ID for the item after further testing. I changed the start of the workflow to wait until a field in the item changes. I set it to wait until the ID field is not 0 (since you cannot set to null), and it still does not work.
6/14/2012 4:13 PM Comment System Account Waiting on ID
6/14/2012 4:13 PM Comment System Account Waiting complete on ID
6/14/2012 4:13 PM Error System Account Coercion Failed: Unable to transform the input lookup data into the requested type.
I have tried other fields as well, like document ID value is not empty, and it will wait, log it finishing the wait, and then fail.
UPDATE This issue has something to do with the Parent Task field. I have solved the issue without having to wait for a period of time by setting the change from above to wait until the Parent Task field is not empty. It then completes the workflow fine.
Anyone know why there is a delay though? I've solved it, but still don't fully understand what takes it so long.
The main fault has been solved (hence the answer), and the remaining point about the reasons for the delay would probably be a discussion point or not specific enough for SO. Any further clarification can be edited in here.