I have a solution including a xUnit-Test-Project and a API-Web-Application-Project.
In my xUnit-Project I have a couple of Integration/System-Tests.
Now I want to trigger all tests instead of command line dotnet test via HTTP-Request http://myservice.com/run-tests.
Is there any concept how to archive this?
Related
I have been using Clojure, ClojureScript, lein, shadow-cljs, Emacs, and CIDER to work on a Clojure/ClojureScript dynamic web app project.
Usually, I build the project by executing the command cider-jack-in-cljs in Emacs, choosing shadow-cljs, then shadow for REPL type, and, finally, app for the building option.
It works fine. I can watch changes on the UI on localhost:3005.
Based on this previous question, I would like to understand better which HTTP server I am using.
Doing a git grep, I can find:
Pedros-MacBook-Air:balance pedro$ git grep ":dev-http"
Pedros-MacBook-Air:balance pedro$ git grep ":http"
shadow-cljs.edn: :http-root "public"
shadow-cljs.edn: :http-port 3005
Hence, I suppose I can conclude the HTTP server is not :dev-http, right?
If so, how can I make :dev-http the default?
Just tweaking shadow-cljs.edn to add :dev-http?
Should I remove current :http-root "public" and :http-port 3005?
:http-root and :http-port in the :devtools part of the build config is the old (and deprecated) style of configuring http servers in shadow-cljs. :dev-http is the new notation.
So your config is identical to setting :dev-http {3005 "public"} (and removing the http parts from :devtools). They are functionally equivalent otherwise.
I am using lintr library in R to find linting issues in the code. I put them into an xml format like this:
<lintsuites>
<lintissue filename="/home/.../blah.R" line_number="36" column_number="1" type="style" message="Trailing blank lines are superfluous."/>
<lintissue filename="/home/.../blahblah.R" line_number="1" column_number="8" type="style" message="Only use double-quotes."/>
</lintsuites>
Now, I would like to fail the Azure devops build when issues like this occur.
I was able to get my tests in a JUnit format like this:
<testsuite name="MB Unit Tests" timestamp="2020-01-22 22:34:07" hostname="0000" tests="29" skipped="0" failures="0" errors="0" time="0.05">
<testcase time="0.01" classname="1_Unit_Tests" name="1_calculates_correctly"/>
<testcase time="0.01" classname="1_Unit_Tests" name="2_absorbed_correctly"/>
...
</testsuite>
And when i do this step in the azure pipeline, my build fails if any tests in the test suite fail:
- task: PublishTestResults#2
displayName: 'Publish Test Results'
inputs:
testResultsFiles: '**/*.xml'
searchFolder: '$(System.DefaultWorkingDirectory)/fe'
mergeTestResults: true
failTaskOnFailedTests: true
I would like something similar for failing the build when there are linting issues. I would also like the users to see what those linting issues are in the build output.
Thanks
This is not possible to achieve a similar result for lintr xml with plishTestResults#2.
The workaround you can try is to use a powershell task to check for the content of your lintr xml file. If the content isnot empty, then fail the pipeline in the powershell task.
Below powershell task will check the content of lintr.xml(<car></car>) and will echo the content to the task logs and exit 1 to fail the task if the content is null.
- powershell: |
[xml]$XmlDocument = Get-Content -Path "$(system.defaultworkingdirectory)/lintr.xml"
if($XmlDocument.OuterXml){
echo $XmlDocument.OuterXml
}else{exit 1}
displayName: lintr result.
You can aslo use below statement in a powershell task to upload lintr xml file to the build summary page where you can download
echo "##vso[task.uploadsummary]$(system.defaultworkingdirectory)/lintr.xml"
You can check here for more logging commands.
Update:
A workaround to show the lintr results in a nice way is to create a custom extension to display html results in azure devops pipeline.
You can try creating a custom extension, and produce a html lint results. Please refer to the answer to this thread an example custom extension to display html
Other developers already submit requests to Microsoft for implementing this feature. Please vote it up here or create a new one.
How can I verify if my code on vim (Unix) has syntax errors?
Is there any command to test the code?
Thank you in advance!
Use a plugin which checks your code.
The one I use, and I'm not alone, is syntactic: https://github.com/vim-syntastic/syntastic
This works for a tons of different languages and even has multiple "lint" engines to choose from for each language. For instance, I use python and can configure syntactic to use one of the following checkers: flake8, pyflakes, pylint and the native python checker. And, yes, it checks vim script as well.
If you can't use any plugins AND only want to debug your vim-scripts, then your best bet is to use vim's own debugger (help debug-scripts). To use this mode:
Start vim in debug mode: vim -D my_broken_script.vim
use :debug to switch into debug mode.
use Ex commands to inspect local variables, echo idx, or global ones: echo g:idx, where idx is the var.
set breakpoints with :breakadd on either functions or files. And delete them with :breakdel
Use profile to investigate performance issues (help :profile): :profile start func and :profile stop
I'm moving from Jenkins to using using Concourse CI to run my Sauce labs e2e tests. Sauce labs groups tests together that have the same build number string:
name: 'Chrome XS',
browserName: 'chrome',
tunnelIdentifier: process.env.TUNNEL_IDENTIFIER,
build: process.env.JENKINS_BUILD_NUMBER,
platform: 'Windows 10',
shardTestFiles: true,
maxInstances: 20,
How can I pass the build number to my script using an environment variable as shown above. The Concourse GUI uses name #number. Is there any way to retrieve this. I tried printing all the environment variables in the docker container but it's not set by default.
Metadata like the build number/ID are intentionally not provided to tasks. See https://concourse-ci.org/implementing-resources.html#resource-metadata
This sounds like potentially a use case for a Sauce Labs resource?
In Concourse, build metadata is only available for resources, not tasks.
An example on using build metadata with resources is to include it as part of build results notification emails. The following blog entry contains more information about it:
http://lmpsilva.typepad.com/cilounge/2016/10/how-to-insert-build-metadata-into-user-notifications-in-concourse.html
If you really want to use build number for versioning, you could try to create your own Concourse resource that would return the version number, however, I would use your code commit number instead. Another alternative would be to use the Semver resource in Concourse: https://github.com/concourse/semver-resource
I would like to pass command line arguments to my Meteor app on start up.
For example --dev, --test or --prod indicating whether or not it is running in dev, test or prod environments. It can then load different resources on start up, etc...
I tried something like this in a /server/server.js
var arguments = process.argv.splice(2);
console.log('cmd args: ' + JSON.stringify(arguments,0,4));
The I ran a test. And quite a few others with just random command line arguments.
meteor --dev
The output in the console is only this.
cmd args: [
"--keepalive"
]
What is the best way to get command line arguments into a Meteor app?
Or, is this even the correct way to solve the higher level problem? and if not, what is the correct way to solve this problem of distinguishing between running enviro?
Meteor doesn't forward command line args to your app, if it doesn't know them. You have multiple possibilities:
Rewrite parts of meteor.js to forward unrecognized args. This shouldn't be too hard, but it's not a pretty solution. And if updates occur you are in trouble. :D
You could write a small config file and change the behaviour of your app based on the configuration options in there. Take a look at this question.
The easiest thing to do is using environment variables. You can read env vars in node like this. After that you can start your app the "express.js" way: $ METEOR_ENV=production meteor
I hope I could help you! :)
The reason it doesn't work is because the meteor command starts a proxy (which gets the arguments you give) and then it starts the meteor app with --keepalive.
process.argv will have correct values if you build Meteor with meteor build --directory /my/build/path and run it.