Is there a way to remove string "[Finished in ...s]" from output every time I build?
The build system has the quiet attribute to do exactly that. Just open the lua build system, e.g. via PackageResourceViewer, add "quiet": true, and save the file. It should look like this:
{
"cmd": ["lua", "$file"],
"quiet": true,
"file_regex": "^(?:lua:)?[\t ](...*?):([0-9]*):?([0-9]*)",
"selector": "source.lua"
}
Related
I have a problem with ionide-fsharp formatter. When I install the extension in VSCode I am not able to automaticaly format a file on save. I have fantomas installed globaly and I tried to go through FSAC, but nothing has helped. I think that I need to put something in VSCode's settings.json like I have a prettier config for typescript.
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
So this is how my own config looks like
"[fsharp]": {
"editor.formatOnSave": true,
"editor.defaultFormatter": "Ionide.Ionide-fsharp"
},
You should ensure that editor.formatOnSave is set to true (either for just the fsharp language or globally) and then FSAC should pick up your globally-installed Fantomas.
Trying to figure out how to get the "X.Y.Z" substituted below when not every file will have that in the name. Simple filespec:
{
"files": [
{
"pattern": "artifacts/",
"target": "repository/project/X.Y.Z/"
}
]
}
Not all of the files have the full version number in them so I can't use a simple placeholder (per this solution). I was wondering if there was some other way to dynamically figure out the part to replace the "X.Y.Z" using some maybe-more-complex syntax?
Thinking about the problem a bit more it occurred to me that I could put the artifacts in a specially-named directory that I could then use to publish from.
{
"files": [
{
"pattern": "artifacts-(*)/",
"target": "repository/project/{1}/"
}
]
}
Tested, and that seemed to do the trick. It just required a little scripting at the end of the build to name that directory with the version number in it.
I configured a task in VSCode to compile a Delphi 2005 dpk. It is working and returning the errors on the "problems view", but it is not showing that errors in the file.
I think it is happening because when I click on an error, I get the error message:
Unable to open 'sr075pro.pas': File not found
(...projectfolder\sr075pro.pas)
But the file is in ...projectfolder\webservices\sr075pro.pas.
I can't find a way to tell to the task that the file is in a subfolder. I tried to use the "relative" option on the "fileLocation" tag without sucess.
The error returned:
Compiling sa_webservices...
Borland Delphi Version 13.0 Copyright (c) 1983,99 Inprise Corporation
sr075pro.pas(99) Error: Undeclared identifier: 'ni'
sa_webservices.dpk(802) Fatal: Could not compile used unit 'sr075pro.pas'
My task configuration:
{
"version": "0.1.0",
"name": "Compilar",
"command": "C:\\Compilers\\compile.bat",
"suppressTaskName": true,
"isShellCommand": true,
"isBuildCommand": true,
"tasks": [
{
"taskName": "Compile sa_webservices",
"isBuildCommand": false,
"isTestCommand": false,
"showOutput": "always",
"args": [
"sa_webservices"
],
"problemMatcher": {
"owner": "external",
"fileLocation": "relative",
"pattern": {
"regexp": "^([\\w]+\\.(pas|dpr|dpk))\\((\\d+)\\)\\s(Fatal|Error|Warning|Hint):(.*)",
"file": 1,
"line": 3,
"message": 5
}
}
}
My compile.bat:
#echo off
#P:
#set arg1=%1
shift
...
if "%arg1%" == "sa_webservices" set arg2="webservices"
...
echo Compiling %arg1%...
cd\%arg2%
dcc32.exe -H -W -Q %arg1%.dpk
Your task configuration is wrong. First of all you don't close all brackets but I guess it's a mistake made by copying and pasting it here on StackOverflow. Otherwise the task configuration wouldn't have worked at all.
Now to the real problem:
DCC32 produces hints and warnings containing relative file paths. These paths are relative to the project file. In your task configuration you define the compiler's output to contain relative paths by setting
"fileLocation": "relative"
Visual Studio Code doesn't know how to build the correct absolute path from the relative paths given by the compiler message. So it guesses your current ${workspaceRoot} (in your case it's projectfolder) would be the absolute path.
This explains why you see errors and warnings which contain wrong file paths. In order to get the correct paths you'll need to tell VSCode the correct path to combine the relative paths with.
You do this by simply adding the correct path to the fileLocation entry in you tasks.json:
"fileLocation": ["relative", "${workspaceRoot}\\webservices"]
The entire tasks.json looks like that:
{
"version": "0.1.0",
"name": "Compilar",
"command": "C:\\Compilers\\compile.bat",
"suppressTaskName": true,
"isShellCommand": true,
"isBuildCommand": true,
"tasks": [
{
"taskName": "Compile sa_webservices",
"isBuildCommand": false,
"isTestCommand": false,
"showOutput": "always",
"args": [
"sa_webservices"
],
"problemMatcher": {
"owner": "external",
"fileLocation": ["relative", "${workspaceRoot}\\webservices"],
"pattern": {
"regexp": "^([\\w]+\\.(pas|dpr|dpk))\\((\\d+)\\)\\s(Fatal|Error|Warning|Hint):(.*)",
"file": 1,
"line": 3,
"message": 5
}
}
}
]
}
It might be easier to find files in the problemMatcher in vscode 1.74, see file location search: v1.74 release notes. There is a new option search for the fileLocation property:
New file location method; search
Previously, problem matchers needed to know exactly where to look for
the problematic files, via the fileLocation property. The supported
methods were absolute, relative, or autoDetect (i.e., check for
relative paths first and opt to absolute paths in case of failure).
However, in workspaces that need to invoke various scripts residing in
nested sub-directories, the developers could have a hard time setting
up their tasks; since such scripts seldom report file paths in a
unified manner (e.g., relative to the workspace's base directory).
To help alleviate the problem, a new file location method, named
search, is introduced in this version. With this method, a deep file
system search will be initiated to locate any captured path. See the
example below on how to setup the search file location method
(although, all parameters are optional):
// ...
"fileLocation": [
"search",
{
"include": [ // Optional; defaults to ["${workspaceFolder}"]
"${workspaceFolder}/src",
"${workspaceFolder}/extensions"
],
"exclude": [ // Optional
"${workspaceFolder}/extensions/node_modules"
]
}
],
// ... } ```
⚠️ Of course, users should be wary of the possibly **heavy file system
searches** (e.g., looking inside `node_modules` directories) and set
the `exclude` property with discretion.
Is it possible to integrate JSHint into Jenkins without using the Checkstyle or JSLint reporter?
The reason why I want to do this is because both reporters by default also show non-errors, which is not what I want (see also JSHint shows non-errors for checkstyle reporter).
Is there a way to integrate JSHint directly?
I had similar problem last week, but I use grunt to run jshint. I simply override jshint options, here is example code:
jshint: {
options: {
jshintrc: '../config/.jshintrc',
},
src1: [
'file1.js',
'file2.js'
],
src2: [
'source/file3.js',
'source/file4.js'
],
jenkins: {
options: {
jshintrc: '../config/.jshintrc',
reporter: 'checkstyle',
reporterOutput: 'jshint.xml',
},
src: [ "<%= jshint.src1 %>", "<%= jshint.src2 %>" ]
},
}
So when you want run jslint on jenkins you simply run:
grunt jshint:jenkins
and output is generated to .xml file. I hope this may help you.
I would like to point out that jsHint will now work with the Report Violations, but you must set the report type to jslint-xml. Here is a sample for the Ant task:
<jshint dir="${js.dir}">
options="${jshint.options}">
<include name="**/*.js"/>
<exclude name="**/*.min.js"/>
<report type="jslint-xml"/>
</jshint>
Use the violations plugin for Jenkins, and put the name of your _jsHint_ XML output in the space forjslint`.
And, it's actually documented in the README.md too. I missed it.
This is an alternate way of implementing #mateusz's excellent answer. Instead of creating an additional target that combines all files with the extra report options, override the report and output only when --jenkins is passed in.
var JENKINS = grunt.option('jenkins');
...
jshint: {
options: {
jshintrc: '../config/.jshintrc',
reporter: JENKINS && 'checkstyle',
reporterOutput: JENKINS && 'jshint.xml'
},
src1: [
'file1.js',
'file2.js'
],
src2: [
'source/file3.js',
'source/file4.js'
]
}
Not only does it avoid repeating the files, but in some cases you cannot combine them all into a single task. In our case, we use different .jshintrc files for sources vs. tests. A side benefit to this method is that you can easily apply the option to other tasks without repeating it for each.
$ grunt jshint --jenkins
My current custom LaTeX sublime build goes:
{
"path":"/bin:/usr/texbin:/usr/bin",
"cmd": ["sh", "-c", "pdflatex main.tex && open main.pdf"],
"file_regex": "^[ ]*File \"(...*?)\", line ([0-9]*)",
"selector": ["source.latex"],
}
And it's working great when I select it manually. However, I'm switching back and forth between python scripts and my latex code, so I want to set the build system to "automatic" and let Sublime know that it needs to run LaTeX for .tex files. I tried source.tex, source.latex, source.LaTeX... I think I'm barking up the wrong tree.
edit: I found out that by pressing Cmd+Alt+P I get some information about what the Syntax Highlighter is aware of. It seems to suggest that the right selector would be text.tex.latex... but it doesn't work.
Have you tried just using "selector": "text.tex.latex", without the square brackets? Worked for me.