Add conformance testing

[mosuem]

Add a workflow for https://github.com/unicode-org/conformance/ testing. This runs the conformance test suite with a custom configuration file, and compares the result against a previous run from the main branch. It fails if more tests are failing then were failing before.

FYI: @sven-oly @echeran

---

• I’ve reviewed the contributor guide and applied the relevant portions to this PR.

Contribution guidelines:

• See our contributor guide for general expectations for PRs.
• Larger or significant changes should be discussed in an issue before creating a PR.
• Contributions to our repos should follow the Dart style guide and use dart format.
• Most changes should add an entry to the changelog and may need to rev the pubspec package version.
• Changes to packages require corresponding tests.

Note that many Dart repos have a weekly cadence for reviewing PRs - please allow for some latency before initial review feedback.

[github-actions]

PR Health

Package publish validation ✔️

Details

Package	Version	Status
package:intl	0.19.0-dev	pre-release version (no publish necessary)
package:intl4x	0.6.1-wip	pre-release version (no publish necessary)
package:intl_translation	0.19.0-dev	pre-release version (no publish necessary)

Documentation at https://github.com/dart-lang/ecosystem/wiki/Publishing-automation.

License Headers ✔️

Details

// Copyright (c) 2023, the Dart project authors. Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Files
no missing headers

All source files should start with a license header.

Unrelated files missing license headers

Files
pkgs/intl_translation/test/two_components/app_messages_all.dart
pkgs/intl_translation/test/two_components/app_messages_all_locales.dart
pkgs/intl_translation/test/two_components/component_messages_fr_xyz123.dart
pkgs/intl_translation/test/two_components/app_messages_fr.dart
pkgs/intl_translation/test/two_components/component_messages_all_locales.dart
pkgs/intl_translation/test/two_components/component_messages_all.dart
pkgs/intl_translation/test/generate_localized/code_map_messages_all.dart
pkgs/intl_translation/test/generate_localized/code_map_messages_all_locales.dart
pkgs/intl_translation/test/generate_localized/code_map_messages_fr.dart
pkgs/intl_translation/example/lib/generated/messages_iw.dart
pkgs/intl_translation/example/lib/generated/messages_de.dart
pkgs/intl_translation/example/lib/generated/messages_all_locales.dart
pkgs/intl_translation/example/lib/generated/messages_en.dart
pkgs/intl_translation/example/lib/generated/messages_all.dart
pkgs/intl_translation/example/lib/generated/messages_de_CH.dart
pkgs/intl_translation/example/lib/generated/messages_es.dart

Changelog Entry ✔️

Details

Package	Changed Files

Changes to files need to be accounted for in their respective changelogs.

Coverage ✔️

Details

File	Coverage

This check for test coverage is informational (issues shown here will not fail the PR).

[mosuem]

Switch to unicode/conformance with ref main as soon as makeScriptConfigurable is merged.

[devoncarew]

lgtm; the main question is which technique we'd prefer for checking again the expected test results - uploading a status file or having one committed to the repo

[devoncarew]

What does this referenceExecSummary file look like? Is is human readable?

You might consider (in this PR or a following one) having a test status file checked into the repo. The CI would then fail if the test results didn't match what was in the file. People fixing tests (or adding new, failing tests) would then need to update the status file as part of their PR.

[mosuem]

It is just the output folder of generateDataAndRun.sh, which contains basically a bunch of JSON files and a HTML view. So it is human readable.

The file might be nice, but I don't know how this would work with the branch protection on the main branch.