Fix env conflicts

[wjhsf]

Adds -v2 to the MRT envs we push to, to avoid conflicts with v3. generated-pwa-v2 exists and is functional. production-v2 and staging-v2 are new ones I have just created. Deployments should work, but the sites won't, because I haven't done all the environment settings and whatnot.

Also: We do checks for DEVELOP (= develop branch) and RELEASE (= release branch). For our current workflow for this branch, DEVELOP is always false and RELEASE is always true. That logic should probably be changed, since some commits on this branch are development work and some are releases.

Description

Types of Changes

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Documentation update
• Breaking change (could cause existing functionality to not work as expected)
• Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

• Removing a public function or component or prop
• Adding a required argument to a function
• Changing the data type of a function parameter or return value
• Adding a new peer dependency to package.json

Changes

• (change1)

How to Test-Drive This PR

• (step1)

Checklists

General

• Changes are covered by test cases
• CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance

You must check off all items in one of the follow two lists:

• There are no changes to UI

or...

• Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
• Changes comply with WCAG 2.0 guidelines levels A and AA
• Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

• Changes include a UI text update in the Retail React App (which requires translation)

[bendvc]

@wjhsf Can you clarify the below statement?

Also: We do checks for DEVELOP (= develop branch) and RELEASE (= release branch). For our current workflow for this branch, DEVELOP is always false and RELEASE is always true. That logic should probably be changed, since some commits on this branch are development work and some are releases.

Why would work on a release branch be development?

[wjhsf]

@wjhsf Can you clarify the below statement?

Also: We do checks for DEVELOP (= develop branch) and RELEASE (= release branch). For our current workflow for this branch, DEVELOP is always false and RELEASE is always true. That logic should probably be changed, since some commits on this branch are development work and some are releases.

Why would work on a release branch be development?

When we have code changes for v2, they are merged into release-2.8.x separately from the release PRs that bump package versions. For example: #1521 #1518 #1512 are development work, #1522 #1519 #1516 are releases.

[vcua-mobify]

Deployments should work, but the sites won't, because I haven't done all the environment settings and whatnot.

What work needs to be done to get sites working / do we need to have the sites working for these environments? Are we running tests against these environments (if so, we probably should have the sites working first before merge)?

[wjhsf]

Deployments should work, but the sites won't, because I haven't done all the environment settings and whatnot.

What work needs to be done to get sites working / do we need to have the sites working for these environments? Are we running tests against these environments (if so, we probably should have the sites working first before merge)?

Just set the proxies and env vars. There aren't any tests running against two of them, because I've just made them, and the one that already exists I'm pretty sure is just so we have a reference to point to for latest v2.

If we're not really using these envs, though, we may want to change our approach and just stop pushing to them. Or copy whatever we're using the v3 envs for and also run them on v2.