how would the JQL look like for this condition?:
Generate a report of all HIGH severity JIRA tickets for a project with key X (or name X) that were created from 9 PM EST to 12 AM EST from the start of the year?
I tried something like :
Project = X AND Severity = "HIGH" AND created > "2015/01/01 21:00" and created < "2015/09/09",
but I need only those issues that are created between 9 PM and 12 AM everyday, from the beginning of the year.
Any ideas would be greatly appreciated.
Unfortunately there seems to be no tool to get the hour from created date but you can workaround it.
My two ideas are:
find these tickets directly on Jira database (if you have access) it should be very easy since there are functions like hour (mySQL) or truncate (postgres)
prepare JQL filter using some generator script - it is definetely less comfortable but possible to achieve even when you have not acces to database. The worst thing is that Jira filter fields accepts only 2000 characters string so you would need to copy that filter few lines by few lines.
Little crazy but ok - it works so what's the idea? The idea is to use startOfYear() JQL function and its *offset version**. For example:
created >= startOfYear(21h) and created < startOfYear(24h)
will give you all tickets from 1 Jan 21:00 - 2 Jan 00:00
then you can use this Python script:
step = 27
maxDay = 1
while maxDay <= 365 + step:
maxDay += step
output = "project = X and Severity = HIGH and ("
for i in range(maxDay-step, maxDay):
output += " (created >= startOfYear(" + str( ( (i-1) * 24 ) + 21) + "h) and created < startOfYear(" + str(i*24) + "h)) or"
output = output[:-3]
output += ")"
print output
print
which will generate you set of JQL requests to copy-paste and execute (it is actually 15 of them - you can see here). Every set bounds 28 days because of 2000 limit of filter input in Jira.
I fixed this issue by writing a custom JQL function and then using that function with a JQL query, which fits well with our requirements :
created >= "2015-01-01" and created <= "2015-12-31" and issue in getIssuesForTimeRange("21", "24")
Related
I'm looking for a function that is almost the opposite of FV().
In cryptocurrency tokens, returns are sometimes quoted as a compounded Annual Percentage Yield (APY). These tokens can make payments in periods which are daily, or even each hour, or each 8 hours, etc.
So I'd like to work out the yield per period, from the compounded APY.
I've looked through the financial functions at Google Sheets > Financial but most of these are way over my head.
Any suggestions would be most welcome!
[Edit] I've tried using FV(), by using 365 periods per year, and (say) $100 for current value, seeing what the outcome is to get an APY - but I have to keep modifying that daily rate until I get close to the APY that's quoted. In other words, I'm trying to do it backwards. Must be a function that can do this though?
After mulling over this for some time, a moment of clarity yielded the surprisingly simple answer.
Given:
p (periods) = 365*3 (ie, each 8 hours, for a year)
= 1095
r (rate) = 1.8%
Then:
APY = (1 + r) ^ p
= (1 + 1.8%) ^ 1095
= 30,466,103,336.2661%
So to get the Rate from the APY it becomes:
r = APY ^ 1/p - 1
= 30,466,103,336.2661% ^ 1/1095 - 1
= 1.8%
I have written a rule like
if
the period of 'Request' is more than 0
then
set the date of 'Request' to due_date - 1 Day;
else
set the date of 'Request' to due_date ;
for period values other than 0 it's working fine but when value of period is 0 it just skips whole rule, i.e it neither go to then nor else.
I am using ODM 8.6 and testing through DVS file.
I have tried same thing in ODM 8.5 and it's working fine there
please help in getting this issue resolved.
Did you try with the latest fixpack?
In general it is poor design for rules to use the else construct. Try to split the rule into 2 different rules:
for period of 'Request'>0, and
for period of 'Request'<0.
How can I set Jenkins to run a job at a particular time?
Like if I'd like to set it to 8:30am every weekday and this is what I could do
H 7 * * 1-5
this randomly picks up 7:35am as running time.
H is a pseudo-random number, based on the hash of the jobname.
When you configured:
H 7
you are telling it:
At 7 o'clock, at random minute, but that same minute very time
Here is the help directly from Jenkins (just click the ? icon)
To allow periodically scheduled tasks to produce even load on the system, the symbol H (for “hash”) should be used wherever possible. For example, using 0 0 * * * for a dozen daily jobs will cause a large spike at midnight. In contrast, using H H * * * would still execute each job once a day, but not all at the same time, better using limited resources.
The H symbol can be used with a range. For example, H H(0-7) * * * means some time between 12:00 AM (midnight) to 7:59 AM. You can also use step intervals with H, with or without ranges.
The H symbol can be thought of as a random value over a range, but it actually is a hash of the job name, not a random function, so that the value remains stable for any given project
If you want it at 8:30 every weekday, then you must specify just that:
30 8 * * 1-5
Take a look at http://www.cronmaker.com/
0 30 8 ? * MON,TUE,WED,THU,FRI *
30 8 * * 1-5
This would start at 8:30am Mon-Fri.
0 and 7 are Sundays.
Not sure what the H does but I am assuming it takes the lower case hex of h and applies 68 which is 35 in decimal... lol. Don't do that.
Following this format:
Minute Hour DayOfMonth DayOfWeek Day
It picks that time because you told it that it can, as imagine you already know:
minute, hour, day of month, month, day of week.
Now you have user H which allows Jenkins to pick at random. So you have told it to run between 7-8 every week day.
Change this to:
30 8 * * 1-5
Hope this helps!
A build that takes about three hours to complete needs to be scheduled for nightly building outside office hours: not sooner than 22:00 and not later than 3:59 next day.
I'd also like to use the "H symbol" to avoid collision with future nightly builds. From in-line help in Jenkins:
To allow periodically scheduled tasks to produce even load on the system, the symbol H (for “hash”) should be used wherever possible. For example, using 0 0 * * * for a dozen daily jobs will cause a large spike at midnight. In contrast, using H H * * * would still execute each job once a day, but not all at the same time, better using limited resources.
(How) can I schedule this using Jenkins? What I've tried was all considered invalid by Jenkins:
H H(22,23,0,1,2,3) * * *
Invalid input: "H H(22,23,0,1,2,3) * * *": line 1:7: expecting "-", found ','
H H22,23,0,1,2,3 * * *
Invalid input: "H H22,23,0,1,2,3 * * *": line 1:4: unexpected token: 22
H H(22-3) * * *
Invalid input: "H H(22-3) * * *": line 1:9: 1 is an invalid value. Must be within 1
and -18
Is it possible to achieve this without using plug-ins?
I think the closest you will get is to use:
H H(0-3) * * * This will run at some point between 0:00 and 3:59
#midnight This will run at some point between 0:00 and 2:59
The H(4-8) construct only works if the second items is larger then the first.
But you might as well fill in the hour yourself. Jenkins actually never changes the hour the jobs runs once it is set. It will basically create some random hour once you save the job and always run the job at that particular time.
Of course, you can also file a bug report or feature request that you should be able to specify this as H(22-3) or better, fix the code and submit a patch ;)
There is no direct support to write the expression like this, but since there is timezone support (now), you can work around this.
# DONT COPY PASTE - THIS DOESNT WORK!
# This is what we would like to write, but is not supported
H H(22-3) * * *
Above expression means we want to build somewhen between 22 PM and 3 AM, this is a 5 hour period, so we could write:
# Assuming we're in GMT+2 we can just shift the timezone
# so 22-03 becomes 10-15 wich is 12 hours earlier so the
# timezone is GMT-10
TZ=Etc/GMT-10
H H(10-15) * * *
I found this workaround in the comments of JENKINS-18313
UPDATE:
There is currently a bug JENKINS-57702 and the timezone GMT-XX is not evaluated correctly. A workaround is to use a equivalent timezone, in this example the one for Hawaii:
TZ=US/Hawaii
H H(10-15) * * *
I have a start month (3), start year (2004), and I have an end year (2008). I want to calculate the time in words between the start and end dates. This is what I'm trying and it's not working..
# first want to piece the start dates together to make an actual date
# I don't have a day, so I'm using 01, couldn't work around not using a day
st = (start_year + "/" + start_month + "/01").to_date
ed = (end_year + "/01/01").to_date
# the above gives me the date March 1st, 2004
# now I go about using the method
distance_of_time_in_words(st, ed)
..this throws an error, "string can't me coerced into fixnum". Anyone seen this error?
You can't just concatenate strings and numbers in Ruby. You should either convert numbers to strings as mliebelt suggested or use string interpolation like that:
st = "#{start_year}/#{start_month}/01".to_date
But for your particular case I think there is no need for strings at all. You can do it like that:
st = Date.new(start_year, start_month, 1)
ed = Date.new(end_year, 1, 1)
distance_of_time_in_words(st, ed)
or even like that:
st = Date.new(start_year, start_month)
ed = Date.new(end_year)
distance_of_time_in_words(st, ed)
See Date class docs for more information.
Given that the context in which you are calling the method is one that knows the methods from ActionView::Helpers::DateHelper, you should change the following:
# first want to piece the start dates together to make an actual date
# I don't have a day, so I'm using 01, couldn't work around not using a day
st = (start_year.to_s + "/" + start_month.to_s + "/01").to_date
ed = (end_year.to_s + "/01/01").to_date
# the above gives me the date March 1st, 2004
# now I go about using the method
distance_of_time_in_words(st, ed)
=> "almost 3 years"
So I have added calls to to_s for the numbers, to ensure that the operation + is working. There may be more efficient ways to construct a date, but yours is sufficient.