When archiving a workspace in Jenkins I want to also archive all the files starting with a dot like .gitignore, my standard pattern of ** to copy everything ignores this. Which pattern should I use?
I was being silly, there is a checkbox that needs checking "Override Default Ant Excludes"
Related
For some reasons, practical or not, rxjs npm package stores BAZEL.build configuration in the package, so when I'm trying to build my project (which has node_modules folder) bazel tries automatically to build something that it's not supposed to build at all.
My question would be - what is canonical way of ignoring some specific folder while building bazel project recursively?
The only way to achieve what I'm looking for that I know of is to point to it explicitly in the command line
bazel build //... --deleted_packages=node_modules/rxjs/src (see user manual)
But I don't want to type this every time.
Bazel recently added a feature for ignoring folders (similar to gitignore).
Simply add node_modules to the .bazelignore file in the root of your project.
Yes, this is expressible as a bazel target pattern:
bazel build -- //... -//node_modules/rxjs/src/...
Full documentation is available at https://docs.bazel.build/versions/master/user-manual.html#target-patterns
According to many different SO-questions, it should be possible to exclude files being copied/deployed using the Task "Copy and Publish Build Artifacts" in the new TFS build system.
However it doesn't work for me (it is not excluding anything). What could I be doing wrong:
This should work (I know the question is old but I needed an answer myself)
**\!(System.Windows.Interactivity.resources.dll|*.dll.config|*fluentassertions*)
This is a known issue of the build task “Copy and Publish Build Artifacts”,bitbonk.
Q: This step didn't produce the outcome I was expecting. How can I fix it?
This step has a couple of known issues:
Some minimatch patterns don't work.
It eliminates the most common root path for all paths matched.
Source Link: Utility: Copy and Publish Build Artifacts
Well, it's nothing business with your settings of minimatch. It's just not work for that build task. Certainly, you can also doulbe check your minimatch with Copy Files task to verify this.
For now, you can avoid these issues by instead using the Copy Files step and the Publish Build Artifacts step.
Note: If it's still not working on copy files step, you should pay attention to the architecture of file when using minimatch. There must be something wrong on it.
The task copies the files base on the contents you entered one line by one line and the "!" only exclude the files during the copy, it does not delete the files that already been copied. So with the "**\*" you entered in the first line, all the files have already been copied and published. You need to remove the first line in "Contents". And for the excluded files, if there are in the same folded, you need to exclude them in one line. For example: using
!?(1.txt|2.txt)
to exclude both 1.txt and 2.txt file instead of using
!1.txt
!2.txt
I seem to be getting a lot of pain with the processing of app.config and token files (we have this working with the older ".11" templates).
It looks like currently (using the ReleaseTfvcTemplate.12.xaml) this is running the tokenisation after the build.
While I can make the app.config / myapp.exe.config stuff work by deliberately copying the .token file into my output folder (so the recursive search finds it) this feels pretty horrid.
As a fix I'm tempted to move lines 182-230 to just before the RunMSBuild task on line 175 (creating a new sequence at that point)
Is this the correct approach or have I missed some documentation somewhere (or a later version of the template?)
Thanks guys... Anyway for future reference I did make the change.
However I had misunderstood the exact nature of the order things happen out of the box which is as follows:
Get the project out of source control
build with msbuild
Copy the .config.token file over the .config file. This is in the TFS template
As part of the deploy to a server then the token entries in the .config files are replaced. This is in the release manager template.
Tests are run in the msbuild binary output folders.
The problem is this doesn't really work if you're using an project type that uses app.config file as the msbuild process renames these output.exe.config during the msbuild stage so you need to create both an output.exe.config (marked as copy to output) and an output.exe.config.token so when the post deploy is the final output gets configured correctly. This also a problem if you want to tokenise some mstest dlls as these typically use an app.config as well. Basically this is a bit of a mess unless you are using web.config.
We worked our way around this by using the modification I suggested above (you need to create a sequence at line 175 and move lines 178-230 up into the sequence, this is GetBuildDirectory variable bits and the if statement) followed by adding an additional deployment stage which copies back onto the build server with the new tokenised files so the mstest can run against them.
So our new process looks like this:
Get the project out of source control
Copy the .config.token file over the .config file i.e app.config.token copied over app.config
build with msbuild (this means we end up with tokenised myapp.exe.config and mytests.dll.config)
As part of the deploy to a server then the token entries in the .config files are replaced. This is a release management step in the release template.
Deploy the tests back into a folder on build server (think this has to be a fixed folder until update 4 of release manager is deployed) the token entries in the .config files are replaced (so our integration tests can use the newly deployed servers). This is a release management step in the release template.
Tests are run in the fixed folder on the build server (rather than the msbuild output directory) so the test wildcard needs to be changed in the tfs build template.
Quick final note we don't use that build directory variable and it's left at blank I'm not convinced this would work if it was set to a value...
The replacement of variables in config files with Release Management happens at deployment time and not at compile time.
When RM deployes your app it inserts the correct variables.
It sounds like you're hitting one of two issues:
You need to include the .token file in your project and make sure it's set to Copy Always, so that it gets copied to the build output folder.
If you're building a web application, I've seen a bug in the release build process template that doesn't touch the contents of the _PublishedWebsites folder. I don't know if it's been fixed in Update 4 or not, but it was definitely still a problem in earlier versions.
I'm using Jenkins to do nightly build of an iOS static framework. The output that I care about is in this directory:
ios/build/Release-iphoneuniversal/MySpecialProject.framework
I'd like to use the "Archive the artifacts" action to archive "MySpecialProject.framework", but when I do this, it creates a whole archive with the entire leading directory structure. The docs say to look at how Ant does this. I'm not familiar with Ant, so I'm at a loss here.
The main point of this is to make the "MySpecialProject.framework" available as as artifact to other projects being built with Jenkins. So, thinking that I could use the "Copy Artifact" plugin to do that. But I can't really get past this thing where it creates a full directory structure here. I just wan "MySpecialProject.framework" to be the top-level artifact.
Thanks in advance.
I fixed my own problem, by putting in an "Execute Shell" command:
mv ios/build/Release-iphoneuniversal/MySpecialProject.framework .
Then in the post-build action, "Archive the artifacts", I was able to just archive "MySpecialProject.framework/**"
This seems to work quite well. Since each time Jenkins runs the job, it creates a new workspace, I don't have to worry about issues with "mv". Works fine.
I'm trying to Deploy a Jar File from an ANT script (with OjDeploy), which compiles successfully. But when I run the main project (Which has the Jar dependency), I get a huge incident, when I analysed the incident log, it says
"Caused by: java.sql.SQLSyntaxErrorException: ORA-00942: table or view does not exist"
I analysed both the jar files (One generated by the ANT script and the other generated from Jdev). I couldn't find any difference b/w Manifest of those two jars. The other folders are also the same, In other words, both are almost the same, or I'm not able to figure out the difference between the two jar files generated.
I know, I'm missing something, config of build.xml or something, but not able to figure out the exact problem.
Thanks,
Shiva Shankar
My guess is that the problem is not in the JAR file but rather in the project that consumes it.
Seems like the DB connection in that project is different than the one in your JAR project - which causes one of the tables that is needed in the DB not be found.
I figured out a way to solve the problem. Not sure what was the cause of this issue, but a couple of changes made both to JAR/EAR build scripts set the things right
While building JAR files:
Uncheck "Make this the project build file" while creating the ANT build file, while the "Include Packaging Tasks (uses OjDeploy)" must be checked.
Remove "nocompile" parameter from tag in the OjDeploy.
While Building EAR files:
Create EAR in the view controller project.
Go to the View Controller Project Properties-> Project Source Path -> Resources, remove the newly created build file dependency, which specifies that the build file is for the whole project and not for the individual project.
Remove "Project" parameter from tag in the OjDeploy. (Ensures to build for the whole application)
Remove "nocompile" parameter from tag in the OjDeploy.
These are the exhaustive set of changes, which I made to ensure the ANT files are building correctly, if you get any other errors after this EAR is deployed, then its definitely due to code, EO/VO or DB related.
Thanks for all the help!!
Shiva Shankar