Slowly going crazy with this one, I am trying to inject Bamboo variables into a text file. I have tried many combinations, but to no avail, cannot seem to get my variable to be replaced during the Atlassian Bamboo build process. I'm running Bamboo on Windows.
Any ideas? This is simply a .txt file that is sent along with my build artifacts.
Whilst not ASP.NET specific, I would eventually like to replace some strings in my Web.config file.
As you can see from the output of my vartest.txt file, no variable combinations are being replaced.
%bamboo.test.variable%
%BAMBOO.test.variable%
%BAMBOO.TEST.VARIABLE%
%BAMBOO_TEST_VARIABLE%
%bamboo_test_variable%
${bamboo.test.variable}
%test_variable%
%TEST_VARIABLE%
%TEST.VARIABLE%
This is my setup (according to the documentation they should be accessible via %BAMBOO_TEST_VARIABLE%):
Those variables are only used for replacing task configuration values or accessing them as environmental variables scripts, they are not substituted in all or any of your source files.
You could run a script that does the replacement using some command-line text tool. See How can you find and replace text in a file using the Windows command-line environment? for some examples.
Then in the script, you can replace ${bamboo.CONNSTRING_PASSWORD} (or whatever format you like) in web.config with the environment variable %BAMBOO_CONNSTRING_PASSWORD%.
Related
I have a configure script to set up some paths for my R package during installation. I wish to edit a file based on some conditions. Is there any way to edit a file from within the configure.ac? It would be great if the solution is provided for all operating systems.
Is there any way to edit a file from within the configure.ac?
configure.ac is not executable, but I suppose you mean that you want the configure script generated from it to edit a file. The configure script is a shell script, and you can cause arbitrary shell code to be included in it, more or less just by including that code at the corresponding point in configure.ac.
The question, then, is how you would automate editing a file with a shell script. There is a variety of alternatives, but sed is high on my list. You will find it on every system that can support Autoconf configure scripts, because such scripts use it internally.
On the other hand, this sort of thing is one of the main activities of a configure script, in the form of creating files (especially makefiles, but not limited to those) from templates. You should consider building your target file of interest from a template in this way, instead of making custom-programmed edits to a file packaged in your program distribution. This would involve
setting output variables containing the chosen content for the parts of the file that need to be configured;
designating the target file as one for configure to build; and
providing the template, maybe by taking a complete example file and replacing each variable part with a reference to the appropriate #output_variable#.
Disclaimer: I am very new here.
I am trying to learn R via RStudio through a tutorial and very early have encountered an extremely frustrating issue: when I am trying to use the read.table function, the program consistently reads my files (written as "~/Desktop/R/FILENAME") as going through the path "C:/Users/Chris/Documents/Desktop/R/FILENAME". Note that the program is considering my Desktop folder to be through my documents folder, which is preventing me from reading any files. I have already set and re-set my working directory multiple times and even re-downloaded R and RStudio and I still encounter this error.
When I enter the entire file path instead of using the "~" shortcut, the program is successfully able to access the files, but I don't want to have to type out the full file path every single time I need to access a file.
Does anyone know how to fix this issue? Is there any further internal issue with how my computer is viewing the desktop in relation to my other files?
I've attached a pic.
Best,
Chris L.
The ~ will tell R to look in your default directory, which in Windows is your Documents folder, this is why you are getting this error. You can change the default directory in the RStudio settings or your R profile. It just depends on how you want to set up your project. For example:
Put all the files in the working directory (getwd() will tell you the working directory for the project). Then you can just call the files with the filename, and you will get tab completion (awesome!). You can change the working directory with setwd(), but remember to use the full path not just ~/XX. This might be the easiest for you if you want to minimise typing.
If you use a lot of scripts, or work on multiple computers or cross-platform, the above solution isn't quite as good. In this situation, you can keep all your files in a base directory, and then in your script use the file.path function to construct the paths:
base_dir <- 'C:/Desktop/R/'
read.table(file.path(base_dir, "FILENAME"))
I actually keep the base_dir assignemnt as a code snippet in RStudio, so I can easily insert it into scripts and know explicitly what is going on, as opposed to configuring it in RStudio or R profile. There is a conditional in the code snippet which detects the platform and assigns the directory correctly.
When R reports "cannot open the connection" it means either of two things:
The file does not exist at that location - you can verify whether the file is there by pasting the full path echoed back in the error message into windows file manager. Sometimes the error is as simple as an extra subdirectory. (This seems to be the problem with your current code - Windows Desktop is never nested in Documents).
If the file exists at the location, then R does not have permission to access the folder. This requires changing Windows folder permissions to grant R read and write permission to the folder.
In windows, if you launch RStudio from the folder you consider the "project workspace home", then all path references can use the dot as "relative to workspace home", e.g. "./data/inputfile.csv"
I am using scalapact for CDC test.
My tests are running fine and the pact file is generated under target>pacts folder.
I have another folder "files" where I want those pact files to be generated after running the pact tests.
Is there any way I configure the default path for pact files?
This is an area that needs some attention in Scala-Pact, however, someone kindly did a PR for us a while ago that lets you set an environment variable called pact.rootDir.
In practice, on linux/mac that variable is a bit tricky to set because of the ., so exporting it or just using -Dpact.rootDir="<my desired path>" in the command arguments doesn't seem to work. Instead, you need to do this:
env "pact.rootDir=<my desired path>" bash. I haven't tried this on Windows so I don't know if you'd have the same issue.
I've just raised an issue to try and make this easier in the future:
https://github.com/ITV/scala-pact/issues/101
As an alternative, note that the pact directory is really kind of a scratch/tmp area to allow Scala-Pact to compile it's output. If you're running this as part of a build script, you may just want to add a step to copy the assets to a new location once they've been generated.
Also, for some reason we made reading from a directory way easier than writing to one. If you need to read from a dir such as during verification, you can just add --source <my desired path> on the command line.
Hope that helps.
When I am trying to copy the file 'Output.xml' from parent folder to target folder, it is not being copied properly i.e: the file size, in the target folder, is different. I am executing the keyword to copy files in my 'Suite Teardown'. Any solution for the issue.
Code written to copy files:
OperatingSystem.Copy Files ${sProjectPath}//output.xml ${sFinalFolder}
The problem is that while the test is running, the output file doesn't exist. It can't exist during suite teardown, because the result of the suite teardown must be part of the log.
If you need the log in another folder, the simplest solution is to tell robot to write it there initially, with the command line option --output or --outputdir.
If you cannot use --output, perhaps the simple solution is to create a script that runs your tests, and then copies the file after it runs. This is mentioned in the user guide in the section titled Creating start-up scripts.
A slightly more complex solution is to use a listener which copies the file in the done method.
Robot run reports are created at the end by robot-framework tool. Hence complete result/report files doesn't exist even in suite teardown.
Best practice would be providing --ouput argument with desired output dir.
More detail you can find from user guide
Robot framework user Guide under section 3.5.1
Note:
The command line option --output (-o) determines the path where the output file is created relative to the output directory. The default name for the output file, when tests are run, is output.xml.
Alternative way is use to rebot command and act on the output file generated by robot run.
When post-processing outputs with Rebot, new output files are not created unless the --output option is explicitly used.
Whether or not it can be done from Robot Framework script, the question is it should be done from Robot Script. These files could be locked and or changed by the current Robot Framework process. If not today, this could well be a part of any future change in this area.
With this perspective I can only recommend to copy these files prior to the start of Robot Framework, and not after. This ensures that the contents of these files are not changed and are fit for the purpose you have in mind.
As these types of actions are typically not part of a Test Case scenario I consider them to be part of the overarching Orchestration. This includes fetching the right version of the test script from version control software, starting Robot Framework, communicating results (ex. email) and safeguarding the test evidence (Log files and other files).
In general these are standard step functionality in a CI tool like Jenkins, Travis CI or Bamboo (to name a few). Even if you have only started on this path, separating this kind of logic from your test script will save you a lot of effort later on.
looks like that Copy Files Kw does not copy the content of output.xml during Teardown ,although it creates file with samename. As A.Kootstra suggested it could be a limitation currently.
Alternative:
in a separate robot script you can rename the file 'output.xml' generated from first script and then can run below command
Copy Files
${sProjectPath}//output.xml ${sFinalFolder}
This copies the whole content
I have two files that come in daily to a shared drive. When they are posted, they come in with the current date as part of the file name. example ( dataset1_12517.txt and dataset2_12517.txt) the next day it posts it will be (dataset1_12617.txt and so on). They are pipe delimited files if that matters.
I am trying to automate a daily merge of these two files to a single excel file that will be overwritten with each merge (file name remains the same) so my tableau dashboard can read the output without having to make a new connection daily. The tricky part is the file names will change daily, but they follow a specific naming convention.
I have access to R Studio. I have not started writing code yet so looking for a place to start or a better solution.
On a Window machine, use the copy or xcopy command lines. There are several variations on how to do it. The jist of it though is that if you supply the right switches, the source file will append to the destination file.
I like using xcopy for this. Supply the destination file name and then a list of source files.
This becomes a batch file and you can run it as a scheduled task or on demand.
This is roughly what it would look it. You may need to check the online docs to choose the right parameter switches.
xcopy C:\SRC\souce_2010235.txt newfile.txt /s
As you play with it, you may even try using a wildcard approach.
xcopy C:\SRC\*.txt newfile.txt /s
See Getting XCOPY to concatenate (append) for more details.