Is there a way to include dynamic paths in FitNesse ?
Assuming I have the following structure
Credentials
- Local
- Customer
- Admin
- Staging
- Customer
- Admin
TestLogin +
In my TestLogin page I would like to something like
!define PLATFORM (Local)
!include .Credentials.${PLATFORM}.Customer
....
My Test Tables
I've also (unsuccessfully) tried defining the path:
!define PATH (.Credentials.${PLATFORM}.Customer)
!include ${PATH}
Edit
The accepted answer, strictly speaking, doesn't answer the question (seems it's not possible) but provides a good alternative.
Could it be that your trying to achieve something like: the example of why one would want symbolic links in the user guide?
Would it be acceptable to switch the 'axes' of your reuse (i.e. create a single suite containing TestLogin and use a symbolic link to include this in the hierarchy for each environment where each hierarchy defines some variables (used in TestLogin) that are specific to that environment)?
Have you tried
!define PLATFORM {!include -c <SampleRoot.Credentials.Local.Customer }
${PLATFORM}
....
My Test Tables
? (note the extra space at the end of the !define)
Depending on the Fitnesse version this might or might not work :)
I'm using v20150814.
Related
This bounty has ended. Answers to this question are eligible for a +100 reputation bounty. Bounty grace period ends in 14 hours.
frans is looking for an answer from a reputable source.
I have a working set of JJB YAML files successfully creating jobs and folders.
I now want to make certain values I use inside those YAML files configurable i.e. when running jenkins-jobs test|update -r jobfolder I want to set values for folder prefixes (to not damage existing production jobs), names for branches, nodes etc.
I don't want to use JJBs defaults approach for this since I'm already using it for configuration at a different place and it results in conflicts when used in projects and jobs together.
The ideal way of doing this I can think of would be a way to call JJB like this
jenkins-jobs test|update --define "folder-prefix=experimental/,node=test-node" -r jobfolder
Giving me variables I can use in the actual job definition files.
Since this option seemingly doesn't exist, I'm currently trying to provide files which contain those variables and somehow 'inject' them in my project.
Those are the approaches I can think of:
1 - having different configuration folders with YAML files inside, I would use like this:
jenkins-jobs test -r experimental-config:jobfolder
jenkins-jobs test -r production-config:jobfolder
with experimental-config and production-config being folders with additional files containing my configuration I can switch between.
But unfortunately I don't know how I would reference values I've defined in different yaml files. Is that even possible?
2 - having include files like described in the documentation
While that sounds promising I didn't manage to actually make this run. I tried to turn the following 'configuration header' I'm already using:
- dynamic-config: &dynamic-config
name: "dynamic-config"
folder-prefix: "experimental/"
node: "test-node"
[Rest of the file making use of dynamic-config]
into something making use of the !include statement like this:
!include: dynamic-config.yaml.inc
[Rest of the file making use of stuff defined in dynamic-config.yaml.inc]
giving me a seemingly unrelated parser error:
yaml.parser.ParserError: expected '<document start>', but found '<block sequence start>'
in "/home/me/my/project.yml", line 11, column 1
so I tried this snippet, which looks more like the example by putting it inside an existing element:
- dynamic-config: &dynamic-config
name: "dynamic-config"
!include: dynamic-config.yaml.inc
giving me a different error but still an error:
yaml.scanner.ScannerError: while scanning a simple key
in "/home/me/my/project.yml", line 7, column 5
could not find expected ':'
in "/home/me/my/project.yml", line 8, column 5
In both cases it doesn't make a difference whether or not the specified include file exists or not, which makes me doubt you can just 'include' a file like this at all.
What am I doing wrong here? Is there a more obvious / straight forward way to customize a jenkins-jobs run?
Update:
I somehow managed to use the !include tag for individual items now, like this:
- dynamic-config: &dynamic-config
name: "dynamic-config"
folder-prefix: !include: job-configs/active/folder-prefix.inc
branch-name: !include: job-configs/active/branch-name.inc
node-name: !include: job-configs/active/node-name.inc
But I wasn't able to put the whole dynamic-config element (with the anchor) into an include file yet.
2nd update:
Looks like I'm trying something similar as the guy from this question.
Can someone confirm, that this is currently still a problem? What's the JJB way of handling this?
was wondering if it is possible to allow global variables like ${PAGE_NAME} be a part of an include?
We have different teams using different feature environments (and more environments coming up) which uses symlinks and includes to environment setup pages. At the moment we're copying everytime the literal path. It is less error prone when we can use the global variables FitNesse has to offer.
For example a simple setup:
root
.Env
.FEAT1 --> connection details to setup/connect env 1.
.FEAT2 --> connection details to setup/connect env 2.
.FEAT300 --> connection details to setup/connect env 300.
.Team1
.FEAT2 --> uses !include -seamless .Env.FEAT2 and uses a symlink to suiteX
.Team10
.FEAT300 --> uses !include -seamless .Env.FEAT300 and uses symlinks to suiteX, suiteB and suiteC
etc
When using include -seamless .Env.${PAGE_NAME} it does not load the include. Preferably we want to use the variables FitNesse offers, but I'm sure we are doing something wrong or using the wrong syntax.
Any suggestions on how to use the global variables in a way we try to achieve?
I tried an other solution by defining the whole include into a variable, but that has unfortunately the same result:
!define includes {!include -seamless .Env.${PAGE_NAME} }
$includes
Writing down the global var itself resolves as expected.
I am writing a custom rule that takes inputs from cc_library, cc_binary, apple_static_library, and a few other platform-specific rules. I'd like to view each API given to me via referencing ctx.attr.foo inside the custom rule's implementation function.
There is a list of providers here https://docs.bazel.build/versions/master/skylark/lib/skylark-provider.html but it doesn't say which rules are using them.
Is there a best practice for viewing what these rules are providing me, or does it require going through the source for each one?
This is how you get all providers and output groups from a target:
bazel cquery my_target --output=starlark --starlark:expr="providers(target)"
You can get a list of providers for a given target with dir. Something like this is helpful for debugging:
def _print_attrs_impl(ctx):
for target in ctx.attr.targets:
print('%s: %s' % (target.label, dir(target)))
Printing from inside a rule you're developing is often helpful too, to verify targets are actually what you expect them to be.
You can also apply dir to the providers themselves, to see what fields they have.
I think (correct me if I am wrong) that it is better to put a / at the end of most of url. Like this: http://www.myweb/file/
And not put / at the end of filenames: http://www.myweb/name.html
I have to correct that in a website with a lot of links. Is there a way I can do that in a fast way. For instance in some programs like Dreamweaver I can use find and replace.
The second case is quite easy with Dreamweaver:
- Find: .html/"
- Replace: .html"
But how can I say something like:
- Find: all the links that end with a directory. Like http://www.myweb/file
- Replace: the same link but with a / at the end. Like http://www.myweb/file/
Your approach may work but it is based on the assumption that all files have a file extension.
There is a distinct difference between the urls http://www.myweb/file and http://www.myweb/file/ because the latter could resolve to http://www.myweb/file/index.php, or any other in the default set configured in your web server. That URL could also reference a perfectly valid file which doesn't contain a file extension, such as if it were a REST endpoint.
So you are correct insofar as you should explicitly add a "/" if you are referring to a directory, for example if you are expecting the web server to look up the correct index page to respond, or doing a directory listing.
To replace the incorrect URLS, regular expressions are your friend.
To find all files which have an erroneous "/" you could use /\.(html|php|jpg|png)\//, adding as many different file extensions into that pipe-separated list as you like. You can then replace that with .$1 or .\1 depending on your tool.
An example of doing this with Perl would be:
perl -pi -e 's/\.(html|php|jpg|png)\//.\1/g' theFileYouWantToCheck.html
Of (if you're using a Linux-based system) you can automate that nicely with find:
find path/to/html/root -type f -name "*.html* | xargs perl -pi -e 's/\.(html|php|jpg|png)\//.\1/g'
which will find all html files in the directory and do an inline find and replace. Assuming you're using version control, it's then easy to see the changes it's applied :)
Update
Solving the problem for adding a slash to directories isn't trivial. The approach I'd take:
Write a script to recurse through your website structure locally, making a list of all files
Parse the HTML files to extract all href=".*" and replace them with href=".*/" only if the end of the URL isn't present in the list extracted by the first script.
Any text-based find and replace is not going to be aware of whether the link is actually to a file or not.
We have a requirement that every piece of code that makes it into production will be reviewed by a senior developer.
The way I have envisioned this working is by a naming convention for branches that regular developers cannot check code into.
Following the SVN recomended directory structure this translates into something like.
[project-name]/trunk/
[project-name]/branches/
[project-name]/branches/development-01
[project-name]/branches/development-02
[project-name]/branches/task-increasefontsize
[project-name]/branches/release-01
[project-name]/branches/release-02
[project-name]/tags/
So in the authz file I would like to have something like the following
[/]
#developers = rw
[/*/branches/release-*]
#developers = r
#senior_developers = rw
However I can't find any evidence that SVN supports * (or any other wildcard character).
Is such a thing possible or do I need a pre-commit hook?
It is possible to do a directory structure of
[project-name]/trunk/
[project-name]/branches/development-01
[project-name]/branches/development-02
[project-name]/branches/task-increasefontsize
[project-name]/branches/release-01
[project-name]/branches/release-02
[project-name]/tags/
[project-name]/releases/
and deny access to releases but that still leaves you having to do one denial listing per project and worse its not adhering to the SVN standard project structure.
It is not possible to have wildcards as you like to use them. For this purpose you should take a look at svnperm.py script (just google for it) it will match exactly this purpose.