FitNesse use global variables to load included pages - fitnesse

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.

Related

define environment variable in traefik2 to be used in the file provider

How would one define environment variables for traefik2 so that they could be used within the dynamic file configuration ? e.g:
[http.routers]
[http.routers.the-rtr]
entrypoints = https
rule = Host(`rtr.$DOMAINNAME`)
where DOMAINNAME would have been defined somewhere (in a file, CLI arguments etc.)
Traefik's dynamic configuration does accept Go templating:
Traefik supports using Go templating to automatically generate repetitive portions of configuration files. These sections must be valid Go templates, augmented with the Sprig template functions.
See https://doc.traefik.io/traefik/providers/file/#go-templating
Note that Go Templating only works with dedicated dynamic configuration files. Templating does not work in the Traefik main static configuration file.
For example, if $DOMAINNAME is set as an environment variable, you can do
rule: Host(`{{ env "DOMAINNAME" | trimAll "\"" }}`)
Note: due to "env" quoting, the trimAll is needed — it might be better solution, but it's the better I've found so far.
Not sure if it's directly supported from traefik product.
I use file provider and in traefik.toml, I have:
[providers.file]
filename = "/etc/traefik/dynamic.config.toml"
watch = true
And I use separate mechanism like envsubst to generate (or regenerate as needed) the dynamic.config.toml file. Since I've watch = true, it gets loaded with latest info by traefik
Basically, the snipped you shared in the question can be used as a template file. Then use envsubst or similar to generate dynamic.config.toml.
Q&A on envsubst that I found useful: How to substitute shell variables in complex text files
Hope that helps.

Project level environment variable in source path

I'd like to specify an environment variable for use in the source path (library path) at a project level.
We often have a couple of versions checked out of our SVN repository at the same time in different directories, and I'd like to specify the repository root for a project in relative terms at a project level. I could then use that path in a project's source path and I wouldn't have to include indecipherable dot dot slashes (..\) in paths.
For example, say I have checked out trunk to c:\projects\trunk. Then underneath there I have a project in <repositoryroot>\Foo\Bar\ under trunk which uses the Delphi Spring framework under <repositoryroot>\components\external\Spring4d. I end up with a whole bunch of directories in the search path with ..\..\External\Spring4D\Source at the beginning. For example ..\..\External\Spring4D\Source\Base\Collections. I would like to be able to be able to use ${Spring4D} instead, producing ${Spring4D}\Base\Collections\, which is much less wordy and it means that if you move a project or component you can change one value and it updates all paths.
I know that you can do this on a Delphi level by specifying paths in Delphi's environment variables, but I would like to achieve the same thing on a project level or repository level.
Does anyone have any ideas on how to achieve this? Are there any settings or even add-ins that would allow this sort of functionality?
You can manually edit your project file (.dproj) and add a variable there:
<PropertyGroup>
<MyVariableName>MyVariableContent</MyVariableName>
</PropertyGroup>
Later on, you can refer to the content of that variable:
<DCC_UnitSearchPath>C:\Components;$(MyVariableName)</DCC_UnitSearchPath>
You can also define a new environment variable (SystemPropertiesAdvanced.exe -> Environment variables -> Add) and then refer to that variable using the same syntax, e.g.:
<DCC_UnitSearchPath>C:\Components;$(PATH)</DCC_UnitSearchPath>
(Note that it is a very bad idea to use PATH here, it's only an example of a variable which will exist in your environment.)
You could also employ some cmd script magic to to create environment variables that point to those subdirectories and at the end call the IDE, so these environment variables are available in the IDE in the same way as global environment variables would be (see pepak's answer for that).
Pointers:
%0 is the name of the current cmd file
use tilde for file name parts

ocaml: Is there an environment variable to set the search path for #use and #load?

I've been wondering, if there is an environment variable to set the search path for #use and #load for the ocaml toplevel.
What I think I know so far:
I can use findlib instead of "raw" #use and #load. findlib looks at some environment variables for the search path.
I can set a search path with -I.
Experiments seem to indicate that CAML_LD_LIBRARY_PATH does not influence #use (script loading) and #load (byte code file loading).
(updated) I can use #directory to add the desired path - but unfortunately this only takes a string literal, so i can't pass something I read from the environment at run time. (Update: I forgot to mention #directory originally and why it doesn't fit my use case).
What I want to do:
Run ocaml programs as scripts
Point ocaml to script libraries and script fragments with an environment variable
Avoid, in some scenarios, to create a full findlib library.
Presently I'm not using ocaml as interpreter, but a wrapper that adds a path to the invocation. I want to avoid the wrapper.
(I hope the questions makes sense now, after you know my use case)
So: Is there an environment variable to set the search path for #use and #load without resorting to a wrapper?
More Details
What I'm currently doing:
#!/usr/bin/env oscript2
#use "MyScript"
#load "SomeModule.cmo"
(* ... more ocaml *)
oscript2 is a wrapper around ocaml that basically sets the search paths for #use and #load, but finally executes the toplevel ocaml withe something like
exec ocaml -I .... ...some-byte-code-modules... "$#"
MyScript and SomeModule.cmo live outside of the "normal" Ocaml search path. The actual location might change, but after login (and working through the profie scripts) there is an environment variable (today it's OSCRIPTLOAD_PATH) that tells me, where alle loadable byte code and ocaml script files might live.
This works well, a variant of that setup has been in use for years (at least 7).
The one thing that bothers me there, is: The wrapper, the simple fact of it's presence, looks homebrew, so I'd like to avoid it, to make a better impression on potential future users of the script collection. What I'd like to do
#!/usr/bin/env ocaml
#use "MyScript"
#load "SomeModule.cmo"
(* ... more ocaml *)
and have ocaml itself pick up the search path from some environment variable (I'm free to change the variable name, that is under my control, but I don't want to install script and byte code libs into the default search path, and, as already stated, I' asking if I can do that without findlib).
Basically (as already stated at the very beginning) I'm looking for an environment variable that controls the search path for #use and #load. I'm not looking for toplevel directives and not for wrappers that retrofit this feature. (Thanks everyone for those suggestions, but unfortunately I've already gone that road, it's feasible, but here I'm looking for an alternative purely for cosmetic reasons).
Recent research didn't bring up that such a variable exists, but I thought I'd be asking here, before giving up on it.
From inside the OCaml toplevel you can use the #directory "foo";; primitive to add an include directory.
Here's a shell script that runs the OCaml toplevel while adding a directory to the search path taken from an environment variable named EXTRA_OCAML_DIR.
#!/bin/sh
ocaml -I "$EXTRA_OCAML_DIR" "$#"
If you run this instead of ocaml, you will have a directory in the load path specified by an environment variable.
It seems a little obvious, but maybe it will spark an idea that is more helpful.

Spark Include tag with variable in href

I want to include a spark view in another spark view.
I've tried to use the include tag.
But it doesn't seem to support variables as part of the href attribute.
Eg.
<include href="_group_${groupData.Type}.spark" />
Does anyone know of any workaround to do this?
The <include> tag is part of the Spark language that gets parsed on the first pass and cannot include variables of its own because the view class file has not yet been generated for the variables to be evaluated. Using <include> is a means of including a static resource of some kind.
I think the thing you may be looking for is the <use import="myFile.spark"/> tag for including other Spark files, or you could just use Spark Partials built in. The problem however is that you're trying to have the included spark files dynamically determined at runtime which I don't think will be possible.
Is there any way you can pre-generate the views for each groupData.Type value using the pre-compilation ability in Spark?
The other option potentially (if you really do need these dynamic at runtime) is to create and maintain an InMemoryViewFolder instance and you can add "virtual" files to it as you pull them out of the database but you still won't get away with using variables inside any Spark language elements because variables "don't exist" at that point in the parsing/rendering pipeline.
Hope that helps,
Rob

FitNesse Suites Variables

I'm working with FitNesse and the first time trying with Suite.
I had my test scripts in many parts as I was receiving Jave Heap errors.
Now I'd thought try using suites.
I have a Fitnesse module that load many variables. This module was included in each Part of the suite so I tried to use this variable module just at the beginning of the suite using the !see function.
Unfortunatly the variables aren't stored and used for the pages in the suite.
How can I pass down the variables?
eg. the variables from VariablesSetUp do not pass down to the other pages.
!see .FitNesse.VariablesSetUp
!see .FitNesse.TestDate1
!see .FitNesse.TestDate2
!see .FitNesse.TestDate3
This is a bit tricky to explain; let me know if I haven't made myself clear.
Cheers
Welcome to Stack Overflow!
I think you want to use the !include markup. Using !include -c PagePath will insert the given page (!define values and all) into the current one.

Resources