-
-
Notifications
You must be signed in to change notification settings - Fork 874
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
allow testing of Jira Cloud #1107
Conversation
28d3b4c
to
d43fbf7
Compare
update error handling in JiraTestManager, remove default flaky
72c09e3
to
e405787
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If CI passes and runs the tests and you take the suggestions into consideration
you 'll get the thumbs up :-) 👍
Thanks for the review! Might get a chance to address them at this tomorrow. It is a bit tricky to have the new Cloud tests run on this PR, I've tried to check it on a fork but it still had some troubles with getting the secrets? Any advice would be appreciated. The fork does confirm that the CI is triggered at the right time, ie after the Server CI has been run, which is good to know at least |
i think you can create your own jira cloud instance, I did so a few months back ... have you tried running it against your own instance already? |
I have and it passes locally, see: #896 (comment) |
Getting my new local windows env up and running is not really trivial... I'll maybe try to make a contributor guide for windows. I'll start with trying to understand how tox works and is configured. For now it's mere magic 😅. |
f6e5808
to
0927b08
Compare
So I've done some more testing on my fork and I think GitHub Actions isn't suitable for running actions with shared secrets. Main reason is that it does not have any mechanism to share secrets with pull requests. The other option I am pursuing right now is using Azure Pipelines, which has a handy feature where we can comment on a pull request to be able to trigger the pipeline. The good thing about this is we can control who's comments it will actually listen to, to be able to trigger the pipeline. This means @studioj and myself for example can be given permissions to do this. Which allows us to vet the pull requests before we run any pipelines on them. The ideal situation would be if GitHub implements an "Approve and Run" button for Actions which enable sharing of secrets. This has been discussed for a long time, but it sounds like it hasn't gotten anywhere unfortunately, e.g.: https://github.community/t/allow-secrets-to-be-shared-with-forks-from-trusted-actions/16525/12 . For now I think the Azure Pipeline option might be best. |
https://github.com/adehad/jira/runs/3795266134?check_suite_focus=true Managed to get something working now with GitHub Actions, would be still good to confirm if you can create a pull request to my fork and that works too ! |
I can have a look this week still |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems ok, I'll try a PR to your fork soon, @adehad do i have permissions or should i fork your fork?
@studioj I don't think you need special permission. I just spent some time trying to figure out how to trigger the cloud tests after the server tests, the previous method I had wasn't triggering on pull requests unfortunately... |
@studioj I'll be out for most of today but will be back tomorrow, do let me know if you have any problems, but hopefully all should be okay! |
i opened a pr on yr fork a week ago, maybe you missed it? |
Oops, I did sorry! I've just approved the work flow run, hopefully we will see it run the Cloud tests successfully! |
* initial attempt of a Jira Cloud github action * reusable workflows to enforce Server passing before Cloud * add opt-in marker for running tests on jira cloud `@allow_on_cloud` * fixes to allow Cloud tests to run update error handling in JiraTestManager, remove default flaky * use property access to `is_jira_cloud_ci` * `create_project()` leadAccountId inline * fix bugs in setting defaults for create_project * set default project template for Cloud correctly * `test_group()` `@allow_on_cloud` * update exception handling to use `JIRAError` over Exception where possible * add docstring to `_project_exists()`
Summary of Changes
create_project()
function when setting up defaults - including ignoring a true id of 0 and not actually looping through all items to find a match@flaky
by default as it was causing silent errors (exceptions were not causing test failures !)test_group.py
to run on Jira Cloud !Developer TODO: