I have created a Bamboo build plan that is supposed to generate artifacts. And it does - I see the generated files on the server. Unfortunately, Bamboo does not copy the files to the desired location -> it does not treat them as artifacts that I can download from Bamboo server.
I am working with Bamboo 4.3.3. The documentation tells me to describe the artifacts location relative to the "working directory", so I am trying to copy everything to ${bamboo.build.working.directory}.
I have tried different location / copy pattern settings, but to no avail.
Where should I put them? I have a scripting environment, and there is no Maven or Ant to help me.
I finally understood what was going on with my artifacts and test results that Bamboo did not see:
Test results: there is a known bug that is affecting all versions up to 4.4.5, which manifests itself in scripting environments. Fortunately, it has a workaround: JUnit Parser: Test results are not found
Bamboo uses system property bamboo.fs.timestamp.precision to define FS timestamp resolution. By default it is set to 100 (ms), please set it to higher value in order to make file date check less strict. Bamboo does the check in the following way:
private boolean isFileRecentEnough(final File file)
{
return file.lastModified() >= (taskStartDate.getTime() - SystemProperty.FS_TIMESTAMP_RESOLUTION_MS.getTypedValue());
}
Other items to check
Double check the task configuration and confirm that it is configured it to look for the test results file in the current working directory of the job (Ex.: C:\Users\ssetayeshfar\bamboo-home-445\xml-data\build-dir\PROJECT-PLAN-JOB) and NOT a sub-directory (Ex. C:\Users\ssetayeshfar\bamboo-home-445\xml-data\build-dir\PROJECT-PLAN-JOB/test-results).
In case test report is not produced by the build (it was produced earlier) use a 'touch' command right before the JUnit task.
Artifacts: at the beginning of my work with Bamboo I did not understand that the working directory is defined PER JOB and tried to copy something produced in a previous job as an artifact of the current one.
Related
I'm attempting to run some selenium tests in my solution that are in a project called SA.SEPA.Web.UI.Selenium as part of a build definition in VSTS, but it is failing to run the Visual Studio Test task with the error...
No test assemblies found matching the pattern: **\*Selenium*.dll.
Search folder is set to - $(System.DefaultWorkingDirectory)
Preceding tasks are a nuget restore and build solution
Can anyone help?
You are specifying $(System.DefaultWorkingDirectory) as the search folder. By default (unless overridden), this points to the Source folder on the Agent.
If you are instructing MSBuild (using the OutDir parameter) to output your assemblies in a specific location then you should use that location.
Edit: If this is an On-premises Agent, it should also be running in interactive mode (not service) if you want to execute any UI tests
I ran into this same error but it was a different cause, so I'm adding my solution here.
I was getting the "no test assemblies found" error when trying to run Selenium tests with VSTS as part of a build.
My problem turned out to be that the test assemblies were not checked into change control (git, through VS2017), and therefore were not part of the build. The folders that contain the test assemblies were ignored during my original check-in by default. Once I added those folders to my repository, the build could find the tests and run them.
We have an MSBuild task that builds our *.sqlproj file, the output of which is loaded back into TeamCity as an artifact for subsequent deployment.
Similar to this user, we are having some unpredictable output file naming happen:
Invalid file names when trying to deploy SSDT project with TeamCity 8
It appears that sometimes, it produces this output file under /bin/Release:
MyProj.sqlproj.dacpac
Then subsequent builds produce this file in the same folder:
MyProj.dacpac
We haven't done indepth testing yet - I was wondering if anyone else has seen similar or has a suggested troubleshooting path?
To be clear, it's the same task, running the same command against the same project - just run repeatedly overtime as new checkins happen.
Sounds like you have conflicting .sqlproj files being checked in.
I'd start by checking the history.
Well, after looking more closely at the build log I could see that the TeamCity MSBuild runner appears to be creating some temporary virtual project files (or something, I don't know for sure because they get deleted) with names like:
MyProj.sqlproj.teamcity
I theorized that this may be confusing MSBuild or one of the targets related to building dacpacs, so I replaced the TeamCity MSBuild build step with a Command Line build step that calls MSBuild on the original project file itself, and this appeared to solve the problem. It now produces the dacpac with the file I'm expecting.
I don't have time to dig further now, but I could believe that there's some logic in the chain somewhere that is deriving the name for the final *.dacpac from the name of the project file being used. My guess is that it just strips off everything after the last "." and attaches the ".dacpac" suffix.
I don't fully know why it would occasionally create a *.dacpac file with the correct name, but I was at times doing a manual build in the TeamCity agent work folder from the commandline on the build server itself, so this may have just been a file leftover from previous executions.
I made changes to Intellij Community Edition (ce). I can compile and run those changes from within the IntelliJ editor. That launches a second instance of IntelliJ ce which is running from classes containing my changes. What I want to do is just run those changes without having to first load the source, compile and run from within IntelliJ.
Netbeans made this easy by just producing an executable as a result of the build. With Intellij, it's not at all clear what has to be done. I have tried the following-
using the Run configuration Intellij itself uses to run the altered classes- this includes setting the working directory , main class, vm options and classpath. Actually, this doesn't work for reasons unknown to me.
on someone's suggestion, running dist.gant in build. This blows up with very many errors which are not helpful (no class def found errors which indicate some confusion on Intellij's part on classpaths somewhere)
Running WinLauncher.exe under bin gives the error message that it can't find VM options file (although it's in bin, (and also for good measure under bin/win with the other files which are co-located with vmoptions in the intellij directory structure for Intellij proper. )
ALl this is just harder than it should be. The solution is to provide an executable as a result of the build and place it in a predictable location.
Has anyone ever actually DONE what I am trying to do- make changes to the community source then use the resultant editor not as a project you're working with in IntelliJ but as the Intellij editor you're working through?
FOLLOW UP
User60561 had the correct answer. Just to mop up the details, in artifacts, there is a compressed file (win.zip for Windows, mac.zip for Mac etc.). In order to run your snapshot, you have to unzip this archive (after which it will have the same name, minus the zip extension) then go into folder "bin". There you'll see two executables: idea.exe and idea64.exe, for 32 and 64 bit versions, respectively. Clicking on these runs your snapshot.
Adjusting contents of the files idea.exe.vmoptions and idea64.exe.vmoptions lets you set the VM parameters to suit yourself, typically people might want to give the VM more memory through the -Xmx value.
It seems straightforward:
To build the distribution archive of IntelliJ IDEA Community Edition, execute build.xml Ant build script in the root directory of the source code. The results of the build execution can be found at out/artifacts.
https://github.com/JetBrains/intellij-community#building
So download ant, and run ant in the directory that you have it stored in. Make sure to use the commandline to launch ant in order to make sure everything is working correctly.
Initially execute getPlugins.bat/sh, then:
Use update.bat/sh according to it's instructions
Or
Click on: Main Menu | Build | IntelliJ IDEA CE build
Copy content of intellij-community\out\deploy (lib, plugins folder) into existing IJ installation (sometimes it is better to delete existing folders if they contain older dependencies or when the installation was of Ultimate version)
I have been trying to integrate JMeter test with Maven and Hudson. I came across this beautiful post on Maven JMeter and got it set up easily.
And then I got to know that Hudson has a performance plugin using with JMeter results could be directly displayed on Hudson dashboard.
Now problem I face is in using Performance plugin of Hudson.
Performance plugin says to specify path of JMeter Report files wherein default path is considered as "**/*.jtl" if no path is specified.
My Maven JMeter tests produce this file under "target\jmeter-reports\GoogleAdvanceSearch.xml"
Notice that an "xml" file is generated here but it is same as ".jtl" file.
I provided the entire path this xml file under "report files" section of Hudson but when ever I initiate a build I encounter following exception after performance test execution -
Performance: Recording JMeter reports 'C:\SelNG\jmeter2\target\jmeter-reports\GoogleAdvanceSearch-100905.xml'
Performance: no JMeter files matching 'C:\SelNG\jmeter2\target\jmeter-reports \GoogleAdvanceSearch-100905.xml' have been found. Has the report generated?. Setting Build to FAILURE
But I know that file is physically available at the location I specified.
To double check if problem is coz of "xml" file and not having ".jtl" file as specified in performance plugin of Hudson. Now I created a build file which would execute JMeter tests and generate ".jtl" file. Now get to see following ".jtl" file generated. "C:\SelNG\jmeter\GoogleSearch.jtl". I specified this path under "Performance Report > Report files" section of Hudson plugin but again encountered same exception on build execution
Performance: Recording JMeter reports 'C:\SelNG\jmeter\GoogleSearch.jtl'
Performance: no JMeter files matching 'C:\SelNG\jmeter\GoogleSearch.jtl' have been found. Has the report generated?. Setting Build to FAILURE
Finished: FAILURE
Though I know that file 'C:\SelNG\jmeter\GoogleSearch.jtl' is physically available at specified location.
What is that I am missing in here? has any one of u come across such problem while using Hudson-Performance plugin?
Thanks in advance
~ T
I hope this will help you a little.
Hudson select job. Choose configure.
Let's focus on paths
This is my path to tests
c:\Hudson\data\jobs\template-peformance-test2-mvn\workspace\trunk\src\test\jmeter\
This is my path to report files
c:\Hudson\data\jobs\template-peformance-test2-mvn\workspace\trunk\target\jmeter-reports\
For Hudson the root starts in job workspace.
My Build conf:
Root POM: trunk\pom.xml
Goals and options: celan verify
Then in Post Build Actions
selected Publish Performance test result report
Performance report JMeter
Report files */target/jmeter-reports/*.xml
I'm using PMEase QuickBuild to perform automated builds of our Maven2 projects and a nightly sanity test to ensure nothing is broken.
The test needs to untar packages which are created by the automated Maven2 projects. The problem is that the package names change frequently due to project versions being incremented all the time.
Does anyone know how I can configure QuickBuild to pick up the version (ideally from the POM file of the individual components), if this is possible at all?
I don't know if this is an option for you but it looks like you can do it the other way around. Quoting Build with Maven:
Control build version
If you want to control the build
version from QuickBuild side, please
follow below steps:
Change the POM file and define the project version as
${buildVersion}. Do not forget to
commit the file into your SCM after
change.
Define a build property like below when define the Maven build
step:
buildVersion=${build.version}
There are maybe other options but I must admit that my knowledge (zero) of QuickBuild is very limited
I created a work around to this issue by having QuickBuild execute a shell script which did the untarring by using wildcards, similar to the following (to avoid computing the exact version):
tar xzf filename-*.tar.gz
I couldn't figure out how to do this in QuickBuild, so I offloaded the work to the shell script.