I have configured my grunt/karma setup according to https://github.com/karma-runner/grunt-karma
I'm also using it together with grunt-contrib-watch as described under https://github.com/karma-runner/grunt-karma#karma-server-with-grunt-watch
Almost everything works great, but how do I configure karma to perform all tests directly when the watch is started?
I start it with karma:unit:start watch but then I must first change a file before the tests are performed.
I have stared at the karma config params at http://karma-runner.github.io/0.8/config/configuration-file.html but still cannot find the correct param.
I haven't used grunt-karma before, but the easiest option is probably to configure your watch task, so that it runs it's tasks at startup. This can be done via options.atBegin. So if you take the example from the grunt-karma documentation, you would write:
watch: {
karma: {
files: ['app/js/**/*.js', 'test/browser/**/*.js'],
tasks: ['karma:unit:run'],
options: {
atBegin: true
}
}
},
Related
I must be missing something obvious. I've got a couple of jobrunr jobs where i'm using the lambda enqueue format version 5.1.6. Like this:
JobId jobId = BackgroundJob.<MyService>enqueue(x -> x.doWork());
I would like to validate the plumbing and work in the jobs is executing via some integration tests with Spring, but don't see the options to run now, eager mode, etc? Thanks
You can't, I'm afraid.
You can mock the JobScheduler and capture the args. JobRunr itself is also tested very well so if you pass a job, you can rest assured it will be enqueued.
You could also put the pollIntervalInSeconds to 5 and use awaitility then to verify your job executed. There are many examples of this in the JobRunr repo.
This is my first question posted on stackoverflow, hence in case I did something incorrectly pleaselet me know.
Description
I am currently working on translation of freestyle projects to declarative pipelines in Jenkins (jenkinsfiles kept in Git repo). The original freestyle job was triggering PowerShell script which needed access to Global name/password pairs defined in Mask Passwords plugin section in Configure System. Solution to this problem was an additional tick in project itself (unfortunately I am not allowed adding screenshots to posts yet, hence editor uploaded screen to imgur and pasted link - please see Screenshot 1):
Screenshot 1
Therefore I started looking for possible implementation of such solution to jenkinsfile, however wothout luck.
My problem
When the script is triggered from the pipeline, it errors out stating that it cannot find relevant passwords (powershell refers to those credentials as to environment variables). This works fine when ran from freestyle project.
Which I reckon is caused by pipeline not being able to reach out to previously mentioned credentials.
What I tried
Wrapping the step into below block:
wrap([$class: 'MaskPasswordsBuildWrapper']) {
bat(batch file launching ps script)
}
Then the above block containing relevant step wrapping into
script {
wrap(...)
}
But none of them worked.
I have taken a look at other plugins like Credentials Binding Plugin or Credentials Plugin but those allow to bind/pass one credential per step, and I need to pass all credentials specified in Jenkins (I am open to move saved credentials to any other location within Jenkins).
I have looked at adding environment variable:
credentials('Credentials-ID')
But the problem is the same as with mentioned plugins.
By any chance, have anyone came across similar situation and know what can be done in order to allow pipeline to access/pass to pipeline all the credentials specified in Jenkins instead of binding/passing them one a time?
All tips are very welcome!
You can do this and the env variable will then be available throughout your job. You could define multiple env variable too.
environment {
// Use credentials() to hide the environment variable's output
MY_PERSONAL_TOKEN = credentials('Credentials-ID')
}
stages {
stage('Test Stage') {
steps {
script {
// do what you need to
}
}
}
}
My Protractor suite generally uses the Chrome non-headless mode so the tests can be monitored and stuff, but I tend to switch often between headless and normal while writing tests. Constantly changing the conf.js file is a hassle so I'd like to be able to do this via a command line argument. Something like the following:
npm test -- --headless
npm test-headless
As you can see I'm running Protractor via npm, so a complex argument construction is not a problem here.
I haven't been able to find a way to do this using uncle Google. Can someone point me in the right direction?
keep it simle. Create two protractor.conf files:
- one for local (non headless purpose) - protractor.local.conf
- another for headless purpose that you have already had
And create some scripts that will run what you need, for example:
"scripts": {
"test-headless": "node ./config/protractor.headless.conf.js",
"test-local": "node ./config/protractor.local.conf.js",
}
A somewhat hackish solution, but it works! Check for this flag (or any other) in your configuration file using node's process.argv global. You can then dynamically configure Protractor accordingly. This is one of the great perks of JS config files.
For example:
const isHeadless = process.argv.includes('--headless');
exports.config = {
capabilities: {
browserName: 'chrome',
chromeOptions: {
args: [
isHeadless && '--headless'
].filter(Boolean)
}
}
};
This does raise a warning in the Protractor CLI:
Ignoring unknown extra flags: headless. This will be an error in
future versions, please use --disableChecks flag to disable the
Protractor CLI flag checks.
As with all hacks you use them with some level of risk. The --disableChecks flag will get rid of the warning and future error, but may introduce other issues.
I am trying to run Karma via node (gulp, specifically) persistently in the background but to manually re-run the tests i.e. I have autoWatch set to false. I start the server with something like:
karma_server = new karma.Server(config.karma)
karma_server.start()
Then elsewhere I would like to trigger the tests running when files are updated outside Karma. The API method that one would expect might work is server.refreshFiles(), but it does not do this.
Internally it seems like executor.schedule() might do the trick, but it seems to be undocumented, private, and inaccessible.
So when autoWatch is turned off, how does one trigger Karma testing with an existing server? I'm sure I must be missing something obvious as otherwise the autoWatch option would always need to be true for the server to be useful.
If you have a server already running you can use the karma runner to communicate with it:
var runner = require('karma').runner,
karmaConfig = {/* The karma config here */};
runner.run(karmaConfig, callback);
The grunt-karma plugin works like this, you can check it out for more info:
https://github.com/karma-runner/grunt-karma/blob/master/tasks/grunt-karma.js
I want to run spring xd with Oracle(11g) which i already have in my environment. Currently my first concern is the jobs UI (my database has existing data of job executions that were performed by spring-batch and i simply want to display the details of those executions).
i'm using spring-xd-1.0.0.M5. I followed the instructions in the reference guide and i changed application.yml to have the following:
spring:
datasource:
url: jdbc:oracle:oci:MY_USERNAME/MYPWD#//orarmydomain.com:1521/myservice
username: MY_USERNAME
password: MYPWD
driverClassName: oracle.jdbc.OracleDriver
profiles:
active: default,oracle
i modified also batch-jdbc.properties to have the database configuration similar to the above.
Yet, when i start xd-singlnode.bat (or either xd-admin.bat) it seems like it ignores my oracle configuration and still uses the default hsqldb.
what am i doing wrong?
Thanks
The likely reason is that we did not upgrade the windows .bat scripts to take advantage of the property overriding via xd-config.yml. If you go into the unix script for xd-singlenode you will see that when java is invoked there there is an option
-Dspring.config.location=$XD_CONFIG
you can for now hardcode your location of that file, use file: as the prefix.
Also, The UI right now is very primitive, you will not be able to see many details about the job execution. There are however many job related commands you can execute in the shell and there is only one gap regarding step execution information as compared to what is available via spring-batch-admin.
The issue to watch for this is https://jira.springsource.org/browse/XD-1209 and it is schedule for the next milestone release.
Let me know how it goes, thanks!
Cheers,
Mark