Closed chrisccoy closed 1 year ago
Welcome to Steampipe @chrisccoy 👍 .
Sorry to see that you are running into issues. I will add more details or observations to this thread once I manage to replicate the issue and figure out the reason for this incosistency.
Thanks for your patience 👍 .
'This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.'
'This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.'
This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.
Describe the bug If I attempt to execute a query against "jira_issue" using the "epic_key" in my "where clause" it does not yield any results. However, if I first query against jira_issue using "key" and then try by "epic_key" it works as expected.
Caveat: I am using a forked plugin, because I am going against an enterprise installation and needed to change the api endpoint path to version "rest/api/2/" and not "rest/api/3/". I assume this works against Jira cloud but scratching my head as to why I need to issue a preemptive query to get it working as expected. I realize this is not the version that was tested on for the original plugin, and perhaps that's my tough luck, but just trying to understand the behavior, because the API is still very similar and works in many cases OOTB.
Steampipe version (
steampipe -v
) Example: v0.16.4Plugin version (
steampipe plugin list
) v0.6.0 (forked to use rest/api/2/)To reproduce
Login to CLI -
steampipe query
Execute query:The above does not yield any results.
Quit the CLI -
.quit
Login to CLI again -
steampipe query
execute a different query first -select * from ccoyjira.jira_issue where key = 'APIGOV-22292'
re-execute the query from first login:
Now, this yields the expected 48 rows.
Expected behavior I'd expect it should work the first time without having to issue an initial query. I realize that this must work against Jira Cloud version 3, but I am struggling to understand why it sort of works with this forked version. I have the LOG LEVEL set to TRACE, but can't seem to determine meaningful discrepancies between the logs that explains why it doesn't work under 1 scenario but does in another.