Fix Continuous Integration change detection

[sureshc]

Description

Drone Continuous Integration builds skip unit tests when the target/base branch is staging-next because the detection of which source code directories have changed attempts to compare to origin/staging which is not present in the Drone container. The git command referencing the origin/staging branch raises an error because it has not been fetched. The best solution would probably be to compare the source code changes against origin/staging-next, but this comparison takes place a few layers down in the Continuous Integration rake call stack where information about what the target branch of the Pull Request that invoked the build is no longer available.

This change, instead, always fetches origin/staging. This assumes that most feature-branches off of the staging-next branch will trigger the same source code change detection when compared against staging.

Reviewer Checklist:

• Tests provide adequate coverage
• Code is well-commented
• New features are translatable or updates will not break translations
• Relevant documentation has been added or updated
• User impact is well-understood and desirable
• Pull Request is labeled appropriately
• Follow-up work items (including potential tech debt) are tracked and linked

[Hamms]

why is it necessary to fetch to a depth?

[sureshc]

I don't see why it's necessary. My intent was to preserve the existing logic that fetches the target branch with a depth of 100 commits.

[sureshc]

Ah, it's needed to support the i18n sync process? 37120d8

[uponthesun]

We specify a depth to do a shallow clone, which is faster. We need a high enough depth so that the commit where the feature branch was cut from the base branch is included (I don't remember exactly which step needs this). The whole thing probably could be improved, haven't looked at it since early last year.

The i18n sync process just adds a lot of new commits to one feature branch, hence the increase to 100 in that commit.

[Hamms]

that's why it's necessary to fetch to a depth for the feature branch, but if we're just fetching the staging branch for the sake of change detection, shouldn't we only need to fetch the latest commit?

[uponthesun]

I'm not sure (don't know what the git command being run is), good point though. Worth testing.

[uponthesun]

• IIRC it's the unit tests that depend on this, not the UI tests. Probably safest just to make the change for both.
• Does this increase the time needed to clone noticeably? If so, I think I'd prefer an approach where git_utils overrides its hardcoded default based on an environment variable.

[sureshc]

Starting fresh with @uponthesun suggestion to use an environment variable to detect we're executing in a Drone build.