Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for remote coverage files #421

Open
jab opened this issue Aug 25, 2023 · 3 comments
Open

Add support for remote coverage files #421

jab opened this issue Aug 25, 2023 · 3 comments

Comments

@jab
Copy link

jab commented Aug 25, 2023

Is your feature request related to a problem? Please describe.

It is common for codebases to have coverage generated remotely by CI jobs, and for the latest coverage data to be available at a predictable URL like http://$host/job/$jobname/lastSuccessfulBuild/artifacts/_coverage_report.dat.

It is currently harder than it should be to use remote coverage files with Coverage Gutters (you have to manually download the latest version of the file and move it into the correct location, which is slower and more error-prone than an automated solution).

Describe the solution you'd like

Allow URLs in the list of coverage files that Coverage Gutters looks for.

This would allow a codebase to set its remote coverage file in its .vscode/settings.json, such that a fresh clone could be opened in VSCode, and Coverage Gutters would already be able to display the coverage data, with no need for the user to manually download or generate coverage data locally first. This would be especially useful for being able to quickly view coverage of fresh clones of multiple large codebases, which is a common need e.g. when onboarding with a new team or company.

@ryanluker
Copy link
Owner

@jab Thanks for the ticket!
Sounds like a useful / cool feature, I might try to work on it for version 2.12.0.

The only hurdle that jumps to mind, is whether vscode lets you download files over the network straight out of the box or if there is some permission stuff that might need to be handled / requested of the person using the extension 🤔.

@mattseddon have you seen anything similar to this in your travels?

@mattseddon
Copy link
Collaborator

It is definitely possible. The RedHat yaml extension lets you use remote schemas to validate your YAML files. Something like this should work (warning this is the first thing that jumped into my head):

  const uri = Uri.parse(
    'https://raw.githubusercontent.com/iterative/dvcyaml-schema/master/schema.json'
  )

  const fs = require('fs')
  const https = require('https')

  const file = fs.createWriteStream(
    './coverage.txt'
  )

  https.get(uri.toString(), (response: any) => {
    var stream = response.pipe(file)

    stream.on('finish', function () {
      // do stuff
    })
  })

Two caveats:

  1. You probably want to keep the file in memory.
  2. There are security risks with this approach.

@ryanluker
Copy link
Owner

It is definitely possible. The RedHat yaml extension lets you use remote schemas to validate your YAML files. Something like this should work (warning this is the first thing that jumped into my head):

  const uri = Uri.parse(
    'https://raw.githubusercontent.com/iterative/dvcyaml-schema/master/schema.json'
  )

  const fs = require('fs')
  const https = require('https')

  const file = fs.createWriteStream(
    './coverage.txt'
  )

  https.get(uri.toString(), (response: any) => {
    var stream = response.pipe(file)

    stream.on('finish', function () {
      // do stuff
    })
  })

Two caveats:

1. You probably want to keep the file in memory.

2. There are security risks with this approach.

Thanks for the input! I agree with the caveats and will keep that in mind 👍🏻.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants