<commit_before># Setting up a specific branch to test staging releases

## Intro
Being releaseduty creates a certain advantage in time as it requires both squirrels to touch lots of the infrastructure and
components that form our release automation pipeline. It's expected that from time to time, whenever we need
to make significant changes to our release automation, staging releases need to be performed before we flip the changes to
production. This is where the releaseduty knowledge comes to rescue!

Historically, we have been using staging releases mostly to test `beta 1` of a new cycle. That is because a `beta` release is our most
common type of release and it is the one we usually start any transformation process with. We used it when we switched to `release
promotion` but also for `tcmigration` projects. This how-to page assumes the same, but a different type of release should behave somewhat
similar. So mainly rather larger changes to the code base, changes that actually impose a staging release beforehand.

## Simulation project branch

Project branch `jamun` has traditionally been our choice to simulate `beta`. We have been using `maple` for simulating nightlies from `central`.

Use cases:
- for `central` -> `beta` staging release we would use `from_repo_url` = `central`  and `to_repo_url` = `jamun`
- for `maple` -> `central` -> `beta` (stuff that lands in `central` and right after that goes in `beta`) staging release we would use `from_repo_url` = `maple`  and `to_repo_url` = `jamun`

## Merge scripts

1.  See the doc [AWS staging instance](mergeduty/howto.md#merge-remote-instance) to see if using a dedicated instance for staging releases would be helpful.

2. Use the <a href="../scripts/staging_merge.py">script</a> to run the merge for you. Parameters are the directory to run the merge in, and the repos to merge_from, and merge_to.  For example:
```
staging_merge.py merge_dir projects/maple projects/jamun
```

3. The script should have created a diff. Check that everything is okay and push to jamun
```sh
hg -R build/jamun diff
hg -R build/jamun commit -m "Uplift from central to jamun"
hg -R build/jamun out -r . jamun
hg -R build/jamun push
```

Optional: reset the staging tools repo using this <a href="../scripts/reset_tools.sh">script</a> to ensure you are using the same version as production.
Optional: reset the staging balrog db which is important for staging release builds so they include recent point releases.  This can be done by making a GET to https://balrog-admin.stage.mozaws.net/__rebuilddb__  This step will take 10-15min to complete, You can confirm by comparing the state of the rules vs production.

## Staging tools

- dev [Ship-it](https://ship-it-dev.allizom.org/)
- staging [release runner](https://dxr.mozilla.org/build-central/rev/5f83e0516fc449586bbce4db4eb759f6cede8781/puppet/manifests/moco-nodes.pp#633)<commit_msg>More fixes<commit_after># Setting up a specific branch to test staging releases

## Intro
Being releaseduty creates a certain advantage in time as it requires both squirrels to touch lots of the infrastructure and
components that form our release automation pipeline. It's expected that from time to time, whenever we need
to make significant changes to our release automation, staging releases need to be performed before we flip the changes to
production. This is where the releaseduty knowledge comes to rescue!

Historically, we have been using staging releases mostly to test `beta 1` of a new cycle. That is because a `beta` release is our most
common type of release and it is the one we usually start any transformation process with. We used it when we switched to `release
promotion` but also for `tcmigration` projects. This how-to page assumes the same, but a different type of release should behave somewhat
similar. So mainly rather larger changes to the code base, changes that actually impose a staging release beforehand.

## Simulation project branch

Project branch `jamun` has traditionally been our choice to simulate `beta`. We have been using `maple` for simulating nightlies from `central`.

Use cases:
- for `central` -> `beta` staging release we would use `from_repo_url` = `central`  and `to_repo_url` = `jamun`
- for `maple` -> `central` -> `beta` (stuff that lands in `central` and right after that goes in `beta`) staging release we would use `from_repo_url` = `maple`  and `to_repo_url` = `jamun`

## Merge scripts

1.  See the doc [AWS staging instance](../mergeduty/howto.md#merge-remote-instance) to see if using a dedicated instance for staging releases would be helpful.

2. Use the <a href="../scripts/staging_merge.py">script</a> to run the merge for you. Parameters are the directory to run the merge in, and the repos to merge_from, and merge_to.  For example:
```
staging_merge.py merge_dir projects/maple projects/jamun
```

3. The script should have created a diff. Check that everything is okay and push to jamun
```sh
hg -R build/jamun diff
hg -R build/jamun commit -m "Uplift from central to jamun"
hg -R build/jamun out -r . jamun
hg -R build/jamun push
```

Optional: reset the staging tools repo using this <a href="../scripts/reset_tools.sh">script</a> to ensure you are using the same version as production.
Optional: reset the staging balrog db which is important for staging release builds so they include recent point releases.  This can be done by making a GET to https://balrog-admin.stage.mozaws.net/__rebuilddb__  This step will take 10-15min to complete, You can confirm by comparing the state of the rules vs production.

## Staging tools

- dev [Ship-it](https://ship-it-dev.allizom.org/)
- staging [release runner](https://dxr.mozilla.org/build-central/rev/5f83e0516fc449586bbce4db4eb759f6cede8781/puppet/manifests/moco-nodes.pp#633)
{'fraction_non_alphanumeric': 0.07377332411886663, 'fraction_numerical': 0.011748445058742226, 'mean_word_length': 4.487203791469194, 'pattern_counts': {'":': 0, '<': 11, '<?xml version=': 0, '>': 17, 'https://': 6, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '4029746', 'n_tokens_mistral': 1702, 'n_tokens_neox': 1565, 'n_words': 806}