-
Notifications
You must be signed in to change notification settings - Fork 696
[Jira]: Migrate get all projects methods to use paginated endpoint for Jira Cloud. #1270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
marinone94
commented
Oct 25, 2023
- Migrate "get all projects" methods to use paginated endpoint for Jira Cloud.
- Update docs.
- Use the correct method in the archive project method.
…loud. Use correct method in archive project function.
Hi @marinone94 , Main idea, just make quite easy steps for understanding code by non-developers |
Codecov ReportAttention:
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #1270 +/- ##
==========================================
- Coverage 34.54% 34.48% -0.07%
==========================================
Files 45 45
Lines 8148 8172 +24
Branches 1124 1131 +7
==========================================
+ Hits 2815 2818 +3
- Misses 5219 5240 +21
Partials 114 114
☔ View full report in Codecov by Sentry. |
How about wrap other methods? |
What do you mean? |
@marinone94 i meant wrap other rest api requests |
In v6.3.6, we bumped atlassian-python-api from 3.41.4. That bump included a [PR](atlassian-api/atlassian-python-api#1270) which changed the way library fetched projects. This somehow affected our project when we fetched visible projects and issue types in the heartbeat. We never fully determined the root cause, but the while loop in the linked PR was suspect. In this commit, we make further improvements to the code that's involved in the heartbeat to make it more efficent. Note that one of the tradeoffs we made for now was hardcoding the maximum number of projects that may be configured at 50. This is due to the way we fetch issue types by project. This is something that we can fix in the future, but is not a problem that we need to solve for now since we only have 26 project configured.
In v6.3.6, we bumped atlassian-python-api from 3.41.4. That bump included a [PR](atlassian-api/atlassian-python-api#1270) which changed the way library fetched projects. This somehow affected our project when we fetched visible projects and issue types in the heartbeat. We never fully determined the root cause, but the while loop in the linked PR was suspect. In this commit, we make further improvements to the code that's involved in the heartbeat to make it more efficent. Note that one of the tradeoffs we made for now was hardcoding the maximum number of projects that may be configured at 50. This is due to the way we fetch issue types by project. This is something that we can fix in the future, but is not a problem that we need to solve for now since we only have 26 project configured.
In v6.3.6, we bumped atlassian-python-api from 3.41.4. That bump included a [PR](atlassian-api/atlassian-python-api#1270) which changed the way library fetched projects. This somehow affected our project when we fetched visible projects and issue types in the heartbeat. We never fully determined the root cause, but the while loop in the linked PR was suspect. In this commit, we make further improvements to the code that's involved in the heartbeat to make it more efficent. Note that one of the tradeoffs we made for now was hardcoding the maximum number of projects that may be configured at 50. This is due to the way we fetch issue types by project. This is something that we can fix in the future, but is not a problem that we need to solve for now since we only have 26 project configured.
In v6.3.6, we bumped atlassian-python-api from 3.41.4. That bump included a [PR](atlassian-api/atlassian-python-api#1270) which changed the way library fetched projects. This somehow affected our project when we fetched visible projects and issue types in the heartbeat. We never fully determined the root cause, but the while loop in the linked PR was suspect. In this commit, we make further improvements to the code that's involved in the heartbeat to make it more efficent. Note that one of the tradeoffs we made for now was hardcoding the maximum number of projects that may be configured at 50. This is due to the way we fetch issue types by project. This is something that we can fix in the future, but is not a problem that we need to solve for now since we only have 26 project configured.
In v6.3.6, we bumped atlassian-python-api from 3.41.4. That bump included a [PR](atlassian-api/atlassian-python-api#1270) which changed the way library fetched projects. This somehow affected our project when we fetched visible projects and issue types in the heartbeat. We never fully determined the root cause, but the while loop in the linked PR was suspect. In this commit, we make further improvements to the code that's involved in the heartbeat to make it more efficent. Note that one of the tradeoffs we made for now was hardcoding the maximum number of projects that may be configured at 50. This is due to the way we fetch issue types by project. This is something that we can fix in the future, but is not a problem that we need to solve for now since we only have 26 project configured.
In v6.3.6, we bumped atlassian-python-api from 3.41.4. That bump included a [PR](atlassian-api/atlassian-python-api#1270) which changed the way library fetched projects. This somehow affected our project when we fetched visible projects and issue types in the heartbeat. We never fully determined the root cause, but the while loop in the linked PR was suspect. In this commit, we make further improvements to the code that's involved in the heartbeat to make it more efficent. Note that one of the tradeoffs we made for now was hardcoding the maximum number of projects that may be configured at 50. This is due to the way we fetch issue types by project. This is something that we can fix in the future, but is not a problem that we need to solve for now since we only have 26 project configured.
In v6.3.6, we bumped atlassian-python-api from 3.41.4. That bump included a [PR](atlassian-api/atlassian-python-api#1270) which changed the way library fetched projects. This somehow affected our project when we fetched visible projects and issue types in the heartbeat. We never fully determined the root cause, but the while loop in the linked PR was suspect. In this commit, we make further improvements to the code that's involved in the heartbeat to make it more efficent. Note that one of the tradeoffs we made for now was hardcoding the maximum number of projects that may be configured at 50. This is due to the way we fetch issue types by project. This is something that we can fix in the future, but is not a problem that we need to solve for now since we only have 26 project configured.