Repository: Cloud-CV/EvalAI
Issue: Travis builds failing across multiple PRs during Code Quality check
Root cause: Configuration Error

#### Description
It appears there is a systemic issue with the Travis CI build pipeline affecting multiple recent Pull Requests. Builds are failing during the `Build, Test & Check Code Quality` stage, which is currently blocking new contributions from being merged.

#### Observed Behavior
The build process exits immediately after the coverage summary is printed. Additionally, there is a large volume of Sass deprecation warnings regarding `@import` rules just prior to the failure.


<img width="881" height="672" alt="Image" src="https://github.com/user-attachments/assets/aa1a957e-a5b2-41e3-aecf-cb44f459ad22" />

<img width="1088" height="655" alt="Image" src="https://github.com/user-attachments/assets/195c407c-233e-4097-be0d-813b64f96a1b" />

The following PRs are currently experiencing this exact failure:
* **PR #4845** (Add purge submission queue feature)
* **PR #4843** (Add documentation for baseline submissions)
* **PR #4840** (Fix Twitter icon in web frontend)

#### Possible Causes
1. **Sass Deprecation:** The transition to Dart Sass 3.0.0 might be causing the CI to treat these warnings as fatal errors.
2. **Coverage Threshold:** The current coverage is at **87.14%**. If there is a "fail-under" requirement higher than this, it may be triggering the build failure.

#### Request for Guidance
Since I am a contributor and still learning the specific CI configurations of this repository, I am not entirely sure if my assessment of the Sass/Coverage logs is correct. Please guide me if I should provide more detailed logs or if there is anything I can do on my end to help resolve this.

Thanks for your time and help!

Hi, I’m a contributor and I noticed multiple PRs failing at the same CI stage.
From the logs, it looks related to Dart Sass @import deprecation warnings after the Sass upgrade.
I can try reproducing this locally and propose either a temporary CI fix or an incremental migration if that helps.


Hi @dhiraj-143r , thanks for the input! I’m actually already looking into this and working on a local reproduction. I'm just waiting for a maintainer to check the issue and confirm the best way forward before I dive too deep into the fix.

Ok

One additional angle that might be worth checking:
- Whether the CI is running Dart Sass 3.x with `--fatal-deprecation` or equivalent flags enabled
- Or if the CI treats warnings as errors via tooling config (e.g. gulp / webpack / sass-loader)

If helpful, I can try reproducing the failure locally with the same Node/Sass versions used in CI and share exact repro steps.

Hi @Nilay-Shahane , thanks for the technical insight! That’s a great point about the `--fatal-deprecation` flag; I’m actually already looking into the tooling config (gulp/sass-loader) to see if that's what's triggering the exit.

I'm currently working on a local reproduction of the failure. Like I mentioned to Dhiraj, I’m just waiting for a maintainer to chime in and confirm the best way forward before I dive too deep into a specific fix. Thanks!



Thanks for sharing the details around this CI failure.

I’d really like to take ownership of this issue if it’s not already assigned.

I’ve already gone through the Travis CI logs carefully and traced where the pipeline exits (right after the coverage summary).
 I’m familiar with **frontend build pipelines**, **Sass/Dart Sass**, and **CI coverage checks**, and I’ve handled similar issues involving:
  - Sass deprecation warnings (`@import` → `@use`)
  - CI failures caused by `fail-under` coverage thresholds
  - Build pipelines breaking after dependency upgrades
 I’m comfortable debugging:
  - `.travis.yml` / CI configs
  - coverage tools (karma / istanbul / nyc)
  - frontend build steps (gulp / sass / webpack-style flows)
  - 
If assigned, I will:
1. Identify whether the failure is caused by Sass warnings being treated as errors or by coverage enforcement.
2. Reproduce the issue locally and verify CI behavior.
3. Propose a **minimal and clean fix** (config update or migration strategy) without impacting existing PRs.
4. Document the root cause clearly so future contributors aren’t blocked by the same issue.

I’m actively looking to contribute meaningfully and learn the project’s CI architecture deeply (also as part of my long-term open-source involvement).  
Happy to follow any guidance or preferred approach from the maintainers.

Please let me know if I can be assigned to this issue — I’d be glad to work on it   
Thanks for your time!