Format timestamp data in pipeline charts
What does this MR do?
This is a follow-up fix to an issue introduced by the changes in !47069 (merged)
Without formatting the timestamp datatypes returned by the database as keys, the lookup of each day can fail if GitLab is configured to run with a Rails time_zone set to anything non-UTC.
This happens due to the use of Date/Time objects for hash lookups, which are influenced by the global Rails configuration and produce a timezoned object that does not equate with the same time in UTC.
Tests added here fail without the fix, displaying an all zero data for the chart.
MR fixes issue #296451 (closed)
Screenshots (strongly suggested)
Does this MR meet the acceptance criteria?
Conformity
-
Changelog entry - Added
-
Documentation (if required) - Not necessary, it is a bug fix for something that has not changed
-
Code review guidelines - Added
-
Merge request performance guidelines - The change does not introduce a large amount of new work
-
Style guides - Followed as far as Rubocop passing checks go
-
Database guides - Does not change anything related to the database, only the result-set obtained back
-
Separation of EE specific content - Feature impacted is not an EE feature
Availability and Testing
The risk is low. The only change being done is that of formatting keys in a standard form before use, and the unit tests added cover default and forced (non-UTC) timezone scenarios.
-
Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process. - Added a data test to existing
WeekChart
test to test UTC or default timezone configurations, and added a second non-UTC exercising test that can trap regressions (verified that it fails when run without the fix portion)
- Added a data test to existing
-
Tested in all supported browsers - Tested that the chart data comes through in the backend with the fix in the broken scenario
- Then tested that the chart loads on the UI on a 13.7.1 patched instance, on Safari, Firefox, and Chrome alone
-
Informed Infrastructure department of a default or new setting change, if applicable per definition of done - Not applicable for this bug-fix
Security
If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:
-
Label as security and @ mention @gitlab-com/gl-security/appsec
- Change is not security-related
-
The MR includes necessary changes to maintain consistency between UI, API, email, or other methods - Change is not security-related, nor invasive
-
Security reports checked/validated by a reviewer from the AppSec team - Change is not security-related