I'm trying to create a notification in sonarqube (4.1.2) that will notify me whenever any new analysis found any new major issues. So I created an alert which is:
new major issues + change since previous analysis + is greater than 0 warning threshold and 0 error threshold
However I'm sometimes am not notify when there's a new major issue on the new analysis. I was wondering about how does this "new major issue" alert works?
Example:
I get major issue A and B in previous analysis. I rerun the analysis this time around after fixing A and B but I introduce major issue C. Will the new major issue be 1 (new major issue C) or -1 (C minus A and B)
New issues metric (major or whatever severity) counts the added issues, not the differential. So in your example, you'll get 1.
So if you've set:
new major issues + change since previous analysis + is greater than 0
warning threshold and 0 error threshold
, then you should see an alert in the dashboard of your project in that example.
Now, your question is about notification on alerts: this notification is sent when the alert level changes. So for example, when your project was OK (green) and passes to ERROR (red). In your example, this means that:
if your project was OK and you add 1 issue, then you'll get a notification that your project turned to RED
but if your project was always RED and you add 1 issue, then you'll get no notification because its alert level remains the same (RED)
Related
I'm trying to place an order using the TWS-API and the python package ib_insync. However, I recognize that the order status is not updated by TWS automatically. Please consider the following snippet:
stock = Stock('BMW', 'SMART', 'EUR')
ib.qualifyContracts(stock)
order = MarketOrder("BUY", 10)
trade = ib.placeOrder(stock, order)
A look into the order status of the trade just made (i.e. with trade.log) reveals the order to remain in the submitted state. For that, see the following screenshot:
Highlighted with the red box, you see the log-command printing the order state "submitted". At that point in time, though, the order got already filled when looking into the TWS.
Interestingly, if I now run ib.sleep() (highlighted in green) and look into the order state afterwards, I can see that the order's state has changed to filled (see blue box). This behavior is what I observed several times. Only after typing ib.sleep() the order state seems to be updated in accordance to what is happening in the TWS.
Shouldn't the state of the order automatically be updated by the TWS-API, or do I really need to update the order myself by quering the state from the TWS API?
Any kind of guidance is greatly appreciated. Many thanks in advance!
I generated plenty of routes (~90.000+) using SUMO's ACTIVITYGEN/DUAROUTER with a configuration file and different durations (--duration-d 1, --duration-d 7, ...).
The resulting .rou.xml is successfully executed by SUMO without serious errors. Just some warnings about invalid departPos.
But when using Veins, I receive the following error message:
<!> Error in module (Veins::TraCIScenarioManagerLaunchd)
Scenario.manager (id=6) at event #2327172, t=25619.2: Model error:
ASSERT: condition count == drivingVehicleCount false in function
processVehicleSubscription,
veins/modules/mobility/traci/TraCIScenarioManager.cc line 640.
I removed the ASSERT condition and displayed both values. count is always higher than drivingVehicleCount.
The included "veins" example is running without any problems.
I am using:
SUMO 0.22.0
OMNeT++ 4.6
Veins 4 alpha 2.
In addition, I tested Veins 3.0 and receive the same error message.
Did somebody encounter the same problem?
Commenting out the ASSERT is totally fine.
In SUMO any vehicle can have one of five states (according to statesvehicleStates_sm.uxf): first, it is loaded, transitions to running when it starts driving, then transitions to arrived when it arrived at its destination. In addition, running vehicles can temporarily become teleporting or parking.
Veins subscribes to these state changes to keep track of the number of driving vehicles. To make sure that the bookkeeping is correct, it compares its own count against SUMO's reported number of active vehicles.
I do not know why the numbers do not match sometimes. It only seems to occur in large congested networks.
We are using the Google Calendar v3 API to return a list of events for a user that have been updated since a point in time.
In the v2 API there was no limitation on setting this date in the past.
If we set the UpdatedMin to a date too far back (like 2 months) then the error is thrown
"The requested minimum modification time lies too far in the past. [410]"
If we set ShowDeleted to false then we do not get the error.
I cannot find any reference to a limitation here. Does anybody know the details of this limit. Unfortunately when synchronising calendars this is a show stopper when synchronisation has not run for a period of time for a calendar (other than running a full list which we would prefer to avoid)
EventsResource.ListRequest lr = new EventsResource.ListRequest(service, c.uc.calendar);
lr.UpdatedMin = c.primaryModTime.ToLocalTime();
lr.ShowDeleted = true;
Events el = lr.Execute();
if (el.Items.Count > 0)
{
the following also discusses this issue but without any resoluton.
https://groups.google.com/forum/#!msg/google-calendar-api/_rk9o45sXT0/3APXqxi8jvkJ
There is some explanation at:
https://developers.google.com/google-apps/calendar/v3/sync
It says that on 410 you should wipe your storage and perform a full sync instead.
Also consider switching to sync tokens as recommended in the last paragraph.
I have following problem with tracking of Magento purchase on Google Analytics (custom theme, different from default checkout process).
My goal settings are following: http://db.tt/W30D0CnL, where step 3 equals to /checkout/onepage/opc-review-placeOrderClicked
As you can see from funnel visualization ( http://db.tt/moluI29d ) after step 2 (Checkout Start) there are a lot of exits toward /checkout/onepage/opc-review-placeOrderClicked which is setted as step 3, but step 3 reporting always 0.
Is there something that I'm missing here?
I've found the problem. Apparently second point (/checkout/onepage) was fired even on the third step.
When I changed it to regex match (/checkout/onepage$) everything started to work.
The Teamcity notification email after build successful only show 10 changes. I want to know how to config in teamcity to show more changes.
Thanks!
you can create the internal.properties in config folder, and included following properties,
teamcity.notification.template.update.interval - how often the templates are reread by system (integer, in seconds, default 60)
teamcity.notification.includeDebugInfo - include debug information into the message in case of template processing errors (boolean, default false)
teamcity.notification.maxChangesNum - max number of changes to list in e-mail message (integer, default 10)
teamcity.notification.maxCompilationDataSize - max size (in bytes) of compilation error data to include in e-mail message (integer, default 20480)
teamcity.notification.maxFailedTestNum - max number of failed tests to list in e-mail message (integer, default 50)
teamcity.notification.maxFailedTestStacktraces - max number of test stacktraces in e-mail message (integer, default 5)
teamcity.notification.maxFailedTestDataSize - max size (in bytes) of failed test output data to include in a single e-mail message (integer, default 10240)
more details see, https://confluence.jetbrains.com/display/TCD9/Configuring+TeamCity+Server+Startup+Properties
Imho, it seems TC does not clearly support anything away from out of the box defaults. In other words, lots of things are apparently configurable but there is no documentation nor will a query to their board receive a reply. Instead, the solution seems to be to assume that all the template files can be edited pretty much at will to provide the desired results.
This issue is a case in point. One user gave a generic answer to how to find/edit the notification template in general;
http://devnet.jetbrains.net/thread/293800
TeamCity 5.1 Email template :: JetBrains Developer Community
devnet.jetbrains.net/thread/293800Feb 7, 2011 – I'm going to begin use TeamCity for our projects. ... getViewChangesUrl(bean.build)}'>${modNum} change<#plural modNum/> ...
Note that he cites the "modNum" value, which is our problematic item. Its default appears to be 10 per out-of-the-box settings. (I don't think we can see that part.) I was able to easily change it by assigning a new value.
In my file [ServerConfigsPath]\config_notifications\email\common.ftl , I now have;
<!-- was #assign modNum=bean.modificationsNumber/ -->
<#assign modNum=100/>
I hope this helps you or another newbie. I love SO!
//sorry for spacing on the code, I can't see how to get it right...