You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
@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?
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
})
})
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 👍🏻.
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.The text was updated successfully, but these errors were encountered: