The github issues api provides a way to get all the issues that were updated at or after a particular time, but is there a way I can get all the issues before a particular time?
If the issues API isn't a good fit, you can falbback on the Issues Search API.
That would at least allows to search from oldest to most recent and filter out the ones that are past the time specified initially.
Example
Let’s say you want to find the oldest unresolved Python bugs on Windows. Your query might look something like this.
https://api.github.com/search/issues?q=windows+label:bug+language:python+state:open&sort=created&order=asc
Filter the result of that query and what is left is all the issues before a certain date.
Related
We are using Dynatrace in our organization for a long time. It is really a great tool for pointing out pain areas in case of performance and knowing what's happening in the system. However we found that reporting is not great. In our setup, data gets wiped-off in 20 days for non-PRD environment. It also looses all the details. To keep a track of underlying calls currently we need to take a screen shot of put the data manually in excel file. This helps us in comparing old results with latest development/ improvement.
We were wondering if there is any Dynatrace API available which can push the pure path information in JSON format. We checked Dynatrace API page. But there is none. Creating excel files manually is waste of time. There is no value addition. Has anyone else found any work around for this?
e.g. for the image we want to have JSON having list of underlying DB calls shown under controller, their start-end time, time consumed details, etc..
Please help
I've come across a very annoying bug in Google Dataprep.
According to this page: https://cloud.google.com/dataprep/docs/html/Window-Transform_57344658, it should be possible to reverse the order of sorting by adding a dash in front of the column name.
However, although the preview shows that the data is correctly sorted, the output will always be sorted in ascending order.
I have tested it in various ways and I'm sure it is a bug in the system.
The formula I'm trying to use is a PREV(column_name, 1) function which is not grouped, but is ordered by column_name and -date.
To subsequently deduplicate the dataset based on this column: If(window==column_name)
Hopefully it will be solved as soon as possible. The current situation asks for a workaround. Does anyone know an elegant solution?
I have been able to reproduce the issue you reported when using a Window function ordered in reverse order using a dash -OrderColumn.
I see that you have already created a Dataprep issue in Public Issue Tracker and another member of the GCP Support team was also able to reproduce this behavior and reported it to the Dataprep team. Cloud Dataprep is a third party product developed and managed by a company called Trifacta, and this issue requires support from their product team. I see that the Trifacta Dataprep team is working on the issue reported, and their first response is that, while they work on this, a quick workaround is to use sort in a separate step.
As a final note, maybe next time you can share screenshots in your question in order to provide an easier understanding of your issue.
This seems to be a common enough problem that there are a lot of entries when one googles for help but nothing has helped me yet.
I am finding that the results provided by the REST API for estimated_steps are wildly different from those that appear in the device app.
I am running a fetch task for users via cron job on a PHP/Laravel app.
I'm using this https://developers.google.com/fit/scenarios/read-daily-step-total - estimated_steps to retrieve the step count.
Some days the data is correct. Some days its wildly different. For instance, on one given day, the REST API gives step count of 5661 while the app shows 11,108. Then there are six seven days when the stream is correct.
Has anyone faced this sort of behavior? I've tested for timezone differences, logged and analyzed the response json to see if i'm making some obvious mistake, but nope.
You may check this How do I get the same step count as the Google Fit app? documentation. Be noted that even when using the right data source, your step count may still be different from that of the Google Fit app.
This could be due to one of the following reasons:
On Wear, the Fit MicroApp when connected will display step counts queried on the phone and transferred over via the Wearable APIs. Other MicroApps accessing local-only data will only get watch steps. We are working on making this easier for developers.
Sometimes the step calculation code for the Google Fit app is updated with bug fixes before we are able to release the fixes to developers (which requires a Google Play Services release). We are also working on making it possible for developers to access fixes at the same time.
The Fit app uses a specific data source for steps and it adds some functionality (which can be seen on the documentation) on top of the default merged steps stream.
You can access the "estimated" steps stream as shown here:
derived:com.google.step_count.delta:com.google.android.gms:estimated_steps
Hope this helps!
Im using Jira with Bitbucket, and I wonder - can I somehow store info about that one or more revisions are related to some ticket, without writing ugly prefixes like ABC-123 in commit-messages?
The only other solution is to login to JIRA UI and create an issue link to the commit page in Bitbucket.
Obviously, this is somewhat more work than just adding ABC-123 in the commit.
Short answer: not really
The problem is that most version control systems don't allow you to store extra structured data related to a commit. The least common denominator is the commit message, so it tends to get used for all kinds of logically separate data, e.g. JIRA issue keys, change the status directions etc. The git notes feature might be used for this.
I'm considering moving my open-source project Flyway from Google Code to GitHub.
One of the features I really like in Google Code's Issue Tracker is the ability to vote and sort issues by the number of votes. This has allowed me to get a good feel of where current pain points lie and what the community feels needs attention or further work.
How can I achieve something similar on GitHub? Is there a way to maintain a democratic approach to Issue Tracking?
There is no built-in ability to do so. Technically speaking, you can only manage issues by
assignee
tags (called labels at github)
milestones
While you can define label systems for lots of differentation criteria like
bug/feature request/...
prio high/low/...
status verified/unverified
it is simply not possible to have something that accumulates votes. So typically you will see "+1" postings as in good old mailing lists. I've seen people using external voting systems (like Google moderator) for issues on github, but that doesn't make a good user experience either.
If you're willing to use a third-party system that integrates with GitHub, you can try GitPoll.