Since I've installed gon, my rake tasks aren't working anymore.
I'm using:
Rails 3.2.22.2
ruby 2.2.0p0
gon-6.0.1
test-unit-3.0.8
I can't uninstall test-unit because:
$ rails c
/Users/me/.rbenv/versions/2.2.0/gemsets/project-gems/gems/activesupport-3.2.22.2/lib/active_support/dependencies.rb:251:in `require': Please add test-unit gem to your Gemfile: `gem 'test-unit', '~> 3.0'` (cannot load such file -- test/unit/testcase) (LoadError)
If I rake -T for example:
rake about # List versions of all Rails frameworks and the environment
... (all rake tasks here) ...
rake tmp:create # Creates tmp directories for sessions, cache, sockets, and pids
invalid option: -T
Test::Unit automatic runner.
Usage: /Users/me/.rbenv/versions/2.2.0/gemsets/project-gems/bin/rake [options] [-- untouched arguments]
-r, --runner=RUNNER Use the given RUNNER.
(c[onsole], e[macs], x[ml])
--collector=COLLECTOR Use the given COLLECTOR.
(de[scendant], di[r], l[oad], o[bject]_space)
-n, --name=NAME Runs tests matching NAME.
Use '/PATTERN/' for NAME to use regular expression.
--ignore-name=NAME Ignores tests matching NAME.
Use '/PATTERN/' for NAME to use regular expression.
-t, --testcase=TESTCASE Runs tests in TestCases matching TESTCASE.
Use '/PATTERN/' for TESTCASE to use regular expression.
--ignore-testcase=TESTCASE Ignores tests in TestCases matching TESTCASE.
Use '/PATTERN/' for TESTCASE to use regular expression.
--location=LOCATION Runs tests that defined in LOCATION.
LOCATION is one of PATH:LINE, PATH or LINE
--attribute=EXPRESSION Runs tests that matches EXPRESSION.
EXPRESSION is evaluated as Ruby's expression.
Test attribute name can be used with no receiver in EXPRESSION.
EXPRESSION examples:
!slow
tag == 'important' and !slow
--[no-]priority-mode Runs some tests based on their priority.
--default-priority=PRIORITY Uses PRIORITY as default priority
(h[igh], i[mportant], l[ow], m[ust], ne[ver], no[rmal])
-I, --load-path=DIR[:DIR...] Appends directory list to $LOAD_PATH.
--color-scheme=SCHEME Use SCHEME as color scheme.
(d[efault])
--config=FILE Use YAML fomat FILE content as configuration file.
--order=ORDER Run tests in a test case in ORDER order.
(a[lphabetic], d[efined], r[andom])
--max-diff-target-string-size=SIZE
Shows diff if both expected result string size and actual result string size are less than or equal SIZE in bytes.
(1000)
-v, --verbose=[LEVEL] Set the output level (default is verbose).
(important-only, n[ormal], p[rogress], s[ilent], v[erbose])
--[no-]use-color=[auto] Uses color output
(default is auto)
--progress-row-max=MAX Uses MAX as max terminal width for progress mark
(default is auto)
--no-show-detail-immediately Shows not passed test details immediately.
(default is yes)
--output-file-descriptor=FD Outputs to file descriptor FD
-- Stop processing options so that the
remaining options will be passed to the
test.
-h, --help Display this help.
Deprecated options:
--console Console runner (use --runner).
Here's the culprit:
invalid option: -T
Test::Unit automatic runner.
With or without rspec, same error.
Current solution: I ended with those lines at the bottom of my application.rb:
Test::Unit::AutoRunner.need_auto_run = false if defined?(Test::Unit::AutoRunner)
first link
Test::Unit.run = true if defined?(Test::Unit) && Test::Unit.respond_to?(:run=)
second link
Anyone with a better idea?
Thank you!
ps: https://github.com/gazay/gon/issues/206
try this on your Gemfile
gem "test-unit", :require => false
or try test-unit 3.1.5.
Related
I need to provide to the binary built with meson build system some git information regarding branch and version used:
git describe --tags
git descibe --help
the problem I have is how retrieve this information with meson,
with the make build I use the following instruction:
GITREF = $(shell git describe --all)
LIB1_VER = $(shell cd ../../lib1;git describe --tags;cd - &>NULL)
so in meson for GITREF I've tried
info_dep = vcs_tag(command : ['git descibe --all'],
input : 'infoBuild.h.in',
output : 'infoBuild.h',
replace_string : 'BRANCHNAME')
where infobuild.h.in is:
#define GITREF "BRANCHNAME"
but when I go to compile with ninja I got
/usr/local/bin/meson --internal vcstagger ../../src/prog1/info/infoBuild.h.in src/prog1/info/infoBuild.h 1.1.0 /home/mariano/clonesIntel/projMes/src/prog1/info BRANCHNAME '(.*)' '/home/mariano/clonesIntel/ProjMes/src/prog1/info/git describe --all'
but I don't find any infoBuild.h,
more over for the LIB1_VER is more difficult because it is in an external folder,
I could overcome this issue with a bash script but is there a way to retrieve both information in meson build?
I see an immediate problem in that it's going to try to run a command 'git describe --all', which is not what you want, as meson will be sure to escape the spaces in your shell so that it treats that as the a single filename, you want ['git', 'describe', '--all']. Of course, that could just be a type in your example.
One option you might consider is a run_command and configure_file, which is a command run at compile time, and produces a result object that you can get string values from. The disadvantage of this compared to vcs_tag (or a custom_target) is that it happens at configure time, as opposed to build time, so you need to reconfigure to update your tags:
res = run_command(['git', 'describe', '--all'], capture : true, check : true)
describe = res.stdout()
version_h = configure_file(
input : 'version.h.in',
output : 'version.h',
configuration : {'PLACEHOLDER' : describe}
)
I have made a python testsuite to test my project. I have added in Makefile.am the variable:
TESTS = ./launcher.sh
launcher.sh contains: tests/testsuite.py
When I do ./launcher.sh, my testsuite is correctly executed.
However, when I do make check, I get the following output:
PASS: launcher.sh
============================================================================
Testsuite summary for spider 1.0
============================================================================
# TOTAL: 1
# PASS: 1
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
============================================================================
How can I hide the default output and use the output of my testsuite ?
The Automake manual contains a whole chapter on testing, which would be helpful for understanding the context of Automake's test suite support. Moreover, it is important to understand that part of the bargain you enter into by using Automake to generate makefiles for you is to accept some limitations on the form and behavior of the resulting build system.
How can I hide the default output and use the output of my testsuite ?
To the best of my knowledge, you cannot hide the default output of make check, but you can cause the output of your test program to be emitted to make's standard output instead of redirected to a file. The easiest way to do this would be to enable the serial test harness by turning on Automake's serial-tests option. That would ordinarily be expressed via the argument to the AM_INIT_AUTOMAKE macro in your configure.ac:
AM_INIT_AUTOMAKE([serial-tests])
Note also that it should not be necessary to wrap your tests/testsuite.py in a shell script. Just make sure it is executable (which it sounds like you have already done), and name it directly, relative path included, in the value of the TESTS variable.
How can I do in meson to run a command after building a target?
Eg. I have an executable:
executable('target.elf', 'source1.c', 'source2.c')
And after target.elf built I want to execute a command (eg. chmod -x target.elf) on it.
I tried custom_target(), but that requires an output. I don't have new output, I just have target.elf. I tried run_command() but I didn't know how to execute it after the building.
executable now has an argument install_mode (added 0.47.0) to specify the file mode in symbolic format and optionally the owner/uid and group/gid for the installed files.
I just noticed that yasushi-shoji has provided this answer already.
The following code should do.
project('tutorial', 'c')
exec = executable('target.elf', 'main.c', build_by_default : false)
custom_target('final binary',
depends : exec,
input : exec,
output : 'fake',
command : ['chmod', '+x', '#INPUT#'],
build_by_default : true)
Note that because I want to always run the fake target, I'm using custom_target(). However, the command chmod + x demo doesn't generate the file fake specified in custom_target(), successive ninja command will always run the target.
If you don't want this behaviour, there are two ways:
You can write a script which chmod the target.elf and then copies it to target, thus effectively creates the target file. Make sure to change the output file in the meson.build if you do so.
If you don't mind typing ninja chmod instead of ninja, you can use run_target().
# optional
run_target('chmod',
command : ['chmod', '+x', exec])
Another alternative is to use install_mode for executable().
Also note that you should always use find_program() instead of plain chmod. This example doesn't use it for simplicity.
When defining a Bamboo plan variable, the page has this.
For task configuration fields, use the syntax
${bamboo.myvariablename}. For inline scripts, variables are exposed as
shell environment variables which can be accessed using the syntax
$BAMBOO_MY_VARIABLE_NAME (Linux/Mac OS X) or %BAMBOO_MY_VARIABLE_NAME%
(Windows).
However, that doesn't work in my Linux inline script. For example, I have the following defined a a plan variable
name: my_plan_var value: some_string
My inline script is simply...
PLAN_VAR=$BAMBOO_MY_PLAN_VAR
echo "Plan var: $PLAN_VAR"
and I just get a blank string.
I've tried this
PLAN_VAR=${bamboo.my_plan_var}
But I get
${bamboo.my_plan_var}: bad substitution
on the log viewer window.
Any pointers?
I tried the following and it works:
On the plan, I set my_plan_var to "it works" (w/o quotes)
In the inline script (don't forget the first line):
#/bin/sh
PLAN_VAR=$bamboo_my_plan_var
echo "testing: $PLAN_VAR"
And I got the expected result:
testing: it works
I also wanted to create a Bamboo variable and the only thing I've found to share it between scripts is with inject-variables like following:
Add to your bamboo-spec.yaml the following after your script that will create the variable:
Build:
tasks:
- script: create-bamboo-var.sh
- inject-variables:
file: bamboo-specs/vars.yaml
scope: RESULT
# namespace: plan
- script: echo ${bamboo.inject.GIT_VERSION} # just for testing
Note: Namespace defaults to inject.
In create-bamboo-var.sh create the file bamboo-specs/vars.yaml:
#!bin/bash
versionStr=$(git describe --tags --always --dirty --abbrev=4)
echo "GIT_VERSION: ${versionStr}" > ./bamboo-specs/vars.yaml
Or for multiple lines you can use:
SW_NUMBER_DIGITS=${1} # Passed as first parameter to build script
cat <<EOT > ./bamboo-specs/vars.yaml
GIT_VERSION: ${versionStr}
SW_NUMBER_APP: ${SW_NUMBER_DIGITS}
EOT
Scope can be local or result. Local means it's only available for current job and result means it can be used in subsequent stages of this plan and releases that are created from the result.
Namespace is just used to avoid naming collisions with other variables.
With the above you can use that variable in later scripts with ${bamboo.inject.GIT_VERSION}. The last script task is just to see that it is working in other scripts. You can also see the variables in the web app as build meta data.
I'm using the above script before the build (in my case compiling C-Code) takes place so I can also create a version.h file that can be used by the source code.
This is still a bit cumbersome but I'm happy with it and I hope it will help others to configure Bamboo. Bamboo documentation could be better. (Still a lot try and error)
I wanted to generate scaffold without stylesheets, and I found these two flags: --skip-stylesheets, --no-stylesheets. What's the difference between them?
If you run rails g scaffold --help, it will show help information for that generator along with a list of options.
Some of the options have default values. For example, if you look at
-y, [--stylesheets] # Generate Stylesheets
# Default: true
You see it defaults to true. If you don't want to generate stylesheets, you can prefix the option with --no to disable that specific option.
The skip-stylesheets option is defined in the [Runtime options] section as follows:
-s, [--skip] # Skip files that already exist
So to answer your question:
--no-stylesheets doesn't generate stylesheets at all
--skip-stylesheets generates stylesheets but skips the ones that already exist.