Add a new bugzilla component Testing::CI Configuration
Categories
(bugzilla.mozilla.org :: Administration, task)
Tracking
()
People
(Reporter: jmaher, Assigned: dkl)
References
Details
Choose One
New Component
- Product: Testing
- New Component: CI Configuration
- Description: Changes to CI infrastructure and scheduling
- Default Assignee or releng@mozilla.org
- Triage Owner: jmaher
- Team Name: Release Engineering
- Reviewers (optional)
- New Bug Template (optional, overrides product new bug template)
here is the template for a new bug (taken from bug 1739692):
Type of Change: Choose One
Hosting or Cloud Provider Change
Example: change machines used at cloud provider for more CPU; move load from AWS -> Azure; add capacity at Bitbar
Hardware Change (add/change/remove specific hardware)
Example: upgrade mac minis to new hardware revision; replace Pixel2 phones with Galaxy S7; add arm64 windows machines to CI
OS Change (add tools to OS, upgrade OS to different version)
Example: upgrade windows 10 -> Windows 11; upgrade OSX 11 to latest security release; add codec/font to CI test machines
Build Type Change
Example: Add android-lite builds+tests to CI; add mingw32 builds and tests to CI; remove osx ccov builds and tests from CI
Test Variant (ci coverage via runtime variant set by preference)
*Example: add fission variant by default on all tests and configuration; *
Team Requesting Work (Responsible party for priority decisions, budget signoff, and triaging issues)
Risk of not completing work
Example: We will not be running automation on the OS that the majority of users run on, will miss opportunities to catch bugs
Which test suites will this change apply to (please be verbose)
Example: xpcshell, browser-chrome, talos; ALL; all unittests; all perftests
Which configs will be affected by this (To capacity plan and set timelines, which platforms and build configs will be affected)
Example: only adding a new build type to linux / all windows: shippable, debug, asan, ccov / desktop only
Other useful info
| Assignee | ||
Comment 1•4 years ago
|
||
All done.
| Assignee | ||
Updated•4 years ago
|
| Assignee | ||
Comment 2•4 years ago
|
||
| Reporter | ||
Comment 3•4 years ago
|
||
:dkl, I see some conflicting information here:
- https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=CI%20Configuration has the comment field with what I asked
- there is a link for a automation form: https://bugzilla.mozilla.org/form.automative, which has different fields.
Could we have the "Automation Request Form" point to a rendered version of the text in the comment?
| Assignee | ||
Comment 4•4 years ago
|
||
(In reply to Joel Maher ( :jmaher ) (UTC -0800) from comment #3)
:dkl, I see some conflicting information here:
- https://bugzilla.mozilla.org/enter_bug.cgi?product=Testing&component=CI%20Configuration has the comment field with what I asked
- there is a link for a automation form: https://bugzilla.mozilla.org/form.automative, which has different fields.
Could we have the "Automation Request Form" point to a rendered version of the text in the comment?
The automative form was created 8 years ago with bug 995000. The rewrite rule that we have now is:
$r->any(
'/:REWRITE_automative' => [REWRITE_automative => qr{form[\.:]automative}])
->to(
'CGI#enter_bug_cgi' => {'product' => 'Testing', 'format' => 'automative'});
I can easily change that to just go to the standard bug form with the Product: Testing and component: CI Configuration automatically selected. It would just become:
$r->any(
'/:REWRITE_automative' => [REWRITE_automative => qr{form[\.:]automative}])
->to(
'CGI#enter_bug_cgi' => {'product' => 'Testing', 'component' => 'CI Configuration'});
Then we can remove the link to the old form and remove the code to avoid confusion. Or... We get rid of the comment template we added with this bug and update the old automative custom bug form to the new questions, etc. and keep it. Which the latter will take more time and we are also trying to move away from the custom forms if possible so there is that.
| Reporter | ||
Comment 5•4 years ago
|
||
:dkl, I think the simple solution of rewriting the rules to point to the new ci configuration area would be good enough:
$r->any(
'/:REWRITE_automative' => [REWRITE_automative => qr{form[\.:]automative}])
->to(
'CGI#enter_bug_cgi' => {'product' => 'Testing', 'component' => 'CI Configuration'});
| Assignee | ||
Comment 6•4 years ago
|
||
(In reply to Joel Maher ( :jmaher ) (UTC -0800) from comment #5)
:dkl, I think the simple solution of rewriting the rules to point to the new ci configuration area would be good enough:
$r->any( '/:REWRITE_automative' => [REWRITE_automative => qr{form[\.:]automative}]) ->to( 'CGI#enter_bug_cgi' => {'product' => 'Testing', 'component' => 'CI Configuration'});
Created bug 1745521 to track this change.
Description
•