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
Related
I have many jenkins jobs using a shared library
#Library('my_shared_library') _
On the folder of each build of each project using the library, there's a local copy of it, for example:
jenkins/jobs/my_project/jobs/builds/10/libs/my_shared_library
That means, it's copied on each build's history.
Plus, I see it also on the project's workspace, under:
jenkins/workspace/my_project#libs/my_shared_library
On this last directory there's sometimes several copies of this, like :
my_shared_library
my_shared_library#2
my_shared_library#tmp
...
Question is, is there some special way of handling this so that there'll be less copies? Or, why's there a copy on the project's workspace and one on the build history?
This ends up creating lots of files, which caused my jenkins to run out of inodes.
In my repository I have some files with the name "build" (automatically generated and/or imported, spread around elsewhere from where I have my bazel build files). These seem to be interpreted by Bazel as its BUILD files, and fail the full build I try to run with bazel build //...
Is there some way I can tell Bazel in a settings configuration file to ignore certain directories altogether? Or perhaps specify the build file names as something other than BUILD, like BUILD.bazel?
Or are my options:
To banish the name build from the entire repository.
To add a gigantic --deleted_packages=<...> to every run of build.
To not use full builds, instead specifying explicit targets.
I think this is a duplicate of the two questions you linked, but to expand on what you asked about in your comment:
You don't have to rename them BUILD.bazel, my suggestion is to add an empty BUILD.bazel to those directories. So you'd end up with:
my-project/
BUILD
src/
build/
stuff-bazel-shouldn't-mess-with
BUILD.bazel # Empty
Then Bazel will check for targets in BUILD.bazel, see that there are none, and won't try to parse the build/ directory.
And there is a distressing lack of documentation about BUILD vs. BUILD.bazel, at least that I could find.
I couldn't find definitive answer: What is the difference in TFS2013 betwenn Clean workspace True/False and Clean build True/False. It's not easy to catch the build server while working and see really what's happening. I think that the difference is that clean workapce will delete the src directory, while the clean build will delete the bin/tst dirs.
If it so - I can't understand why is there need to delete the src directory though. It seems that the cleanst way to do build requires only to clean the work tree (along with bin/tst) and get latest above it, and not deleting it and get all the sources again.
If so - how can I perform this type of cleaning? Or I understood it wrong?
The background is that we have heavy sources (>1GB) and not very good network between the tfs server and the build server. We would glad to cut it off, but also clean the src tree before the build.
For "Clean Workspace" setting, there are three options. And this setting is used to set whether to delete source/output folders in the build agent working directly. (by default is: $(SystemDrive)\Builds\$(BuildAgentId)\$(BuildDefinitionPath))
All: delete all existing outputs and sources and do a full rebuild;
Outputs: to delete all existing outputs but get only those source files that have changed since the last build (Incremental Get);
None: to leave existing outputs and sources in place and build any changes incrementally.
However, I can't find Clean Build (True|False) setting, do you mean delete builds or Retention Policy?
For your scenario, you need to set "Clean Workspace" to be "Output", then the output folder is deleted but still have source folder.
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 have two jobs in my Hudson configuration. Let's call them A and B.
Job A was created specifically to generate a folder application_home. This folder is a ready-to-be-used-in-installations-application-home-folder.
Job B is the "pack-all-together-for-installation-job". It needs to copy the application_home generated by job A to generate the installer. My problem is that after some investigation, I was not able to do this in a simple way.
I could use shell script, but then I would need to know job A path plus where its workspace is to get application_ home folder.
Is there a simpler way to do this?
EDIT
I know Copy Artifact Plugin. The problem is that it only copies artifacts. I need to copy the folder application_ home as it is, because it's already in the structure to be used in the installer. If there's a way to use this plugin to copy only the folder, I haven't found it.
EDIT 2. Answer:
Ok, you can do it using Copy Artifact Plugin. You need to
Set its configuration to "copy from WORKSPACE of latest completed build".
Set Artifacts to copy option the folder like this: target/application_home/**
Set Target directory to where you want to somethine like: installation_bundle_folder/application_home.
and it's done :)
You could try the Copy Artifact Plugin.
Then you could add a build step to "pack-all-together-for-installation-job" that would copy application_home to the packaging directory. There is an option to only include the latest stable build of Project A.
Another alternative is to have a post-build step for a successful Project A build that scripts the copy of the application_home over to where Project B will use it. You can use the WORKSPACE environment variable to get the absolute location. (See here for a list of environmental variables).