Skip to content
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

Add a setting for testing on bugzilla staging instance #242

Closed
aminomancer opened this issue Feb 2, 2023 · 3 comments
Closed

Add a setting for testing on bugzilla staging instance #242

aminomancer opened this issue Feb 2, 2023 · 3 comments
Assignees

Comments

@aminomancer
Copy link
Member

aminomancer commented Feb 2, 2023

I just noticed the test bugs in Bugzilla. Just in case you didn't know, there's a staging instance of Bugzilla at https://bugzilla-dev.allizom.org/ - If possible, it would be better to test on that rather than on the production instance.

Originally posted by @Standard8 in #238 (comment)

We have a file prefs.js with some debugging/development settings. You can add a new pref there that flips the origin from https://bugzilla.mozilla.org to https://bugzilla-dev.allizom.org. I think there are a couple files with API URL related definitions, so you may want to consolidate anything that references https://bugzilla.mozilla.org into a single exported symbol. And then just have those various files import ROOT_URL or whatever, where ROOT_URL is defined in relation to the new setting.

To avoid rate limits you may need to create a new account and API key for this instance (the API key is specified as an environment variable, so for testing on the BMO instance you can just use your own personal key from the BMO settings page, same with testing on the staging instance). So if you do run into rate limits, you can ask for someone to help set an account up in the #bmo slack channel. Any other questions just ask me on slack.

@aminomancer
Copy link
Member Author

And also please add a comment above the new setting explaining that, when doing any kind of testing that requires creating or altering bugs or any other bugzilla data, the setting should be enabled and the created/altered bugs should exist on the staging instance instead of on BMO.

For general development, modifying bugs is not necessary, so there's no need for the setting to be enabled by default under any circumstances, and the comment should make clear that it isn't necessary for development except when changes are being made to bugzilla data for the sake of testing.

@aminomancer
Copy link
Member Author

Btw I'm guessing our metabugs and bugzy epic don't exist on this instance, but some of the views should still work. Like the new UnassignedView or the OtherView. As long as the test bugs are in Messaging System, they should appear in at least some of the queries.

@aminomancer
Copy link
Member Author

Putting this on hold since the staging site doesn't mirror our iterations within the last 3 yrs, making bugzy unusable

@aminomancer aminomancer closed this as not planned Won't fix, can't repro, duplicate, stale Feb 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants