Travis should natively support the official YAML standard’s recommended file extension of yaml when reading a project’s continuous integration configuration files, allowing developers to use .travis.yaml to define their CI configuration and further enabling developers to have consistency of all their YAML files, while using the recommended extension.
Note: This request in no way asks for the current CI configuration filename of .travis.yml to be removed, deprecated, or otherwise changed; the only expectation of this feature requests is that Travis additionally support an alternative filename of .travis.yaml as well.
This feature has been requested for just short of a decade, both within the travis-ci/travis-ci GitHub repository issue tracker, as well as in issue trackers of external projects relying on Travis, many of which link to one of the closed issues within their official issue tracker. For example, see travis-ci/travis-ci#672, travis-ci/travis-ci#8068, zalando/zappr#148, or clockworksoul/helm-elasticsearch#24 as evidence that this feature is highly requested.
A related feature (originally submitted as travis-ci/travis-ci#5519, and further discussed on the community forums) asks for the location of the CI configuration file to be customizable in the web IU. While implementation of such a feature would enable a work-around for developers who use .yaml in their project and desire consistency throughout, I do not consider it an acceptable solution for the issue of supporting the yaml extension by default, and its acceptance or rejection is therefore ultimately inconsequential to the importance of supporting the yaml extension by default; I do not believe developers should be required to define a custom CI configuration file location when they are using the extension that is recommended by the body that standardized the YAML file-format!
The .yaml extension needs to be natively supported for Travis CI configuration files by default, and without any additional configuration required of the developer. For additional thoughts, see my original issue comment about this feature request, posted on one of the closed issues from Travis’s GitHub tracker, where no one from their organization has responded to any user comments regarding this request since April of 2016, almost a full three years ago. Hopefully someone from Travis follows up on this request soon.