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

Bug 1927890 - Hardcode beetmover-apt-promote task to level 1 worker #9998

Merged
merged 1 commit into from
Oct 29, 2024

Conversation

ahal
Copy link
Collaborator

@ahal ahal commented Oct 29, 2024

For now there isn't a good place for us to import the candidate package during the promote phase for QA to be able to test. So we use the "staging" apt repo. However, this lives in the non production GCP project, so we have to use the level 1 workers.

In the future we'll want to either:

  1. Create a second apt repo in the production GCP project that we can use for QA prior to shipping.
  2. Import the package into the main mozillavpn production apt repo but with a different name (e.g include rc### or similar). Then add a repackage task that renames it to the proper name during the ship phase.

Description

Describe your changes

Reference

i.e Jira or Github issue URL

Checklist

  • My code follows the style guidelines for this project
  • I have not added any packages that contain high risk or unknown licenses (GPL, LGPL, MPL, etc. consult with DevOps if in question)
  • I have performed a self review of my own code
  • I have commented my code PARTICULARLY in hard to understand areas
  • I have added thorough tests where needed

@ahal ahal self-assigned this Oct 29, 2024
For now there isn't a good place for us to import the candidate package
during the promote phase for QA to be able to test. So we use the
"staging" apt repo. However, this lives in the non production GCP
project, so we have to use the level 1 workers.

In the future we'll want to either:
1. Create a second apt repo in the production GCP project that we can
   use for QA prior to shipping.
2. Import the package into the main `mozillavpn` production apt repo but
   with a different name (e.g include `rc###` or similar). Then add a
   repackage task that renames it to the proper name during the ship
   phase.
@ahal ahal marked this pull request as ready for review October 29, 2024 19:42
@ahal ahal requested a review from a team as a code owner October 29, 2024 19:42
@ahal ahal requested review from hneiva and removed request for a team October 29, 2024 19:42
Copy link
Contributor

@bhearsum bhearsum left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ahal ahal merged commit c55901c into mozilla-mobile:main Oct 29, 2024
112 of 114 checks passed
@ahal ahal deleted the push-opvlxtrllsps branch October 29, 2024 20:50
mcleinman pushed a commit that referenced this pull request Oct 30, 2024
…9998)

For now there isn't a good place for us to import the candidate package
during the promote phase for QA to be able to test. So we use the
"staging" apt repo. However, this lives in the non production GCP
project, so we have to use the level 1 workers.

In the future we'll want to either:
1. Create a second apt repo in the production GCP project that we can
   use for QA prior to shipping.
2. Import the package into the main `mozillavpn` production apt repo but
   with a different name (e.g include `rc###` or similar). Then add a
   repackage task that renames it to the proper name during the ship
   phase.
mcleinman added a commit that referenced this pull request Oct 30, 2024
…9998) (#9999)

For now there isn't a good place for us to import the candidate package
during the promote phase for QA to be able to test. So we use the
"staging" apt repo. However, this lives in the non production GCP
project, so we have to use the level 1 workers.

In the future we'll want to either:
1. Create a second apt repo in the production GCP project that we can
   use for QA prior to shipping.
2. Import the package into the main `mozillavpn` production apt repo but
   with a different name (e.g include `rc###` or similar). Then add a
   repackage task that renames it to the proper name during the ship
   phase.

Co-authored-by: Andrew Halberstadt <ahal@mozilla.com>
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 this pull request may close these issues.

2 participants