Does anyone know of a Jenkins plugin which will allow you to easily set your own values for the "Changes" portion of a build?
We're manually performing our own SCM syncs, and so we don't currently have access to or know how to change the "Changes" portion of the build status.
Thank you for your help!
There is no specific plugin to do it.
Each builds change log is saved in a location like "C:\Program Files (x86)\Jenkins\jobs\BuildJobName\builds\2014-09-11_21-30-25\changelog.xml"
You can manually edit it or write an app which edits the changelog.xml
The format of the changelog.xml is as follows.
<?xml version="1.0" encoding="UTF-8"?>
<log>
<logentry revision="16349">
<author>LeoN</author>
<date>2014-10-24T08:33:57.708042Z</date>
<paths>
<path action="M" localPath="Binaries\Plugins\product.wxs" kind="file">/trunk/Project Phases/Development/Binaries/Plugins/product.wxs</path>
<path action="M or D or A" localPath="LocalPath From repo" kind="dir or File">Svn Path</path>
</paths>
<msg> Fixed Issues.</msg>
</logentry>
</log>
Action attribute can have values such as M,D,A
M - Modifications
D - Deletes
A - File or folder additions
I suggest you write an app to do this.
Related
I've gotten some weird effects lately, where sometimes when I deploy my CQ application via Maven to my local AEM Server, it would't update correctly.
E.g. when changing something in a dialog of a component, I have to delete the /app/myapp folder in CRX and deploy again to get changes to appear.
I'm also having a hard time reproducing the effect. It happens seemingly in random intervals.
Please check your filter.xml file. This descriptor should contain all the root paths for your application so most probably: /app/myapp, /etc/designs/myapp and maybe couple others.
For more information please check vault documentation (section using filters). This file is used by CQ package manager to install the content.
In previous CQ versions there was a behaviour that filters were almost ignored. Starting from CQ 5.6 if any content path does not match filter.xml regexps it won't be installed. This does not match exactly your issue but kindly check if updating filter.xml file helps.
Here is what I use for our project and has worked flawlessly on AEM6 but should also work perfectly on CQ 5.6. Replace "ourProject" with whatever is appropriate and let me know if you still have issues.
<?xml version="1.0" encoding="UTF-8"?>
<workspaceFilter version="1.0">
<filter root="/apps/ourProject">
<exclude pattern=".*install" />
</filter>
<filter root="/etc/ourProject"/>
<filter root="/etc/designs/ourProject" />
<filter root="/etc/widgets" />
<filter root="/etc/workflows" mode="update"/>
</workspaceFilter>
We're using nugetter to make a nupkg as part of our build process for a solution that only builds occasionally, and that we want to distribute in the future. We also want to use this package in other solutions we have. So far, I've been able to generate a package that we can install. Now, I want to be sure that this package updates its version every time it's built so we can update the package easily. I'm thinking that using the build number would be a good way to do this, but I'd be willing to use just about any incrementing scheme if I don't have to start writing a powershell script to update the nuspec for package on every build.
Is there a way to do this automatically in nugetter?
If not, is there something easier than modifying the nuspec with powershell?
We're trying to do the same thing. NuGetter ships with a build process template that builds on top of TfsVersioning. Are you using that already? If so, all you have to do is add a special element for your NuGet package ID to the VersionSeed.xml file.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VersionSeed>
<Solution name="Your Solution Name">
<!-- This is the pattern used to replace the AssemblyVersion value. -->
<AssemblyFileVersionPattern>1.0.J.B</AssemblyFileVersionPattern>
<!-- This is the pattern used to replace the AssemblyVersion value. -->
<AssemblyVersionPattern>1.0.0.0</AssemblyVersionPattern>
</Solution>
<NuGetPackage id="Your NuGet Package ID">
<!-- This is the pattern used to replace the version attribute in the NuSpec file. -->
<VersionPattern>1.0.J.B</VersionPattern>
</NuGetPackage>
</VersionSeed>
It's not a very well documented NuGetter feature, but it's in their help file somewhere.
Also, you still have to set the <version> attribute in the NuSpec file. Currently, I force it to 0.0.0.0 because it is overridden by the build process anyway. Removing the <version> element completely seems to always result in a crash.
To deploy to different azure environments I modify the csdef as part of the compilation step to change the host headers. Doing so requires building the cspkg once for each environment instead of being able to reuse the cspkg and specify different configs for deployment.
I would like to instead modify the csdef file of a cspkg after it has been created, without recompiling. Is that possible, and if so how?
I've done something similar to what you're after to differentiate between test and live environments. First of all you need to create a new .csdef file that you want to use for your alternate settings. This needs to be the complete file as we're just going to swap it out with the original one. Now we need to add this to the cloud project. Right click on the cloud project and select unload project. Right click on it again and select Edit [Name of project]. There's a section that looks a bit like this:
<ItemGroup>
<ServiceConfiguration Include="ServiceConfiguration.Test.cscfg" />
<ServiceDefinition Include="ServiceDefinition.csdef" />
<ServiceConfiguration Include="ServiceConfiguration.cscfg" />
</ItemGroup>
Add a new ServiceDefinition item that points to your newly created file. Now find the following line:
<Import Project="$(CloudExtensionsDir)Microsoft.WindowsAzure.targets" />
Then add this code block, editing the TargeProfile check to be the build configuration you're wanting to use for your alternate and ensuring that it points to your new .csdef file
<Target Name="AfterResolveServiceModel">
<!-- This should be run after it has figured out which definition file to use
but before it's done anything with it. This is all a bit hard coded, but
basically it should remove everything from the SourceServiceDefinition
item and replace it with the one we want if this is a build for test-->
<ItemGroup>
<!-- This is an interesting way of saying remove everything that is in me from me-->
<SourceServiceDefinition Remove="#(SourceServiceDefinition)" />
<TargetServiceDefinition Remove="#(TargetServiceDefinition)" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' == 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.Test.csdef" />
</ItemGroup>
<ItemGroup Condition="'$(TargetProfile)' != 'Test'">
<SourceServiceDefinition Include="ServiceDefinition.csdef" />
</ItemGroup>
<ItemGroup>
<TargetServiceDefinition Include="#(SourceServiceDefinition->'%(RecursiveDirectory)%(Filename).build%(Extension)')" />
</ItemGroup>
<Message Text="Source Service Definition Changed To Be: #(SourceServiceDefinition)" />
</Target>
To go back to normal, right click on the project and select Reload Project. Now when you build your project, depending on which configuration you use, it will use different .csdef files. It's worth noting that the settings editor in is not aware of your second .csdef file so if you add any new settings through the GUI you will need to add them manually to this alternate version.
If you would want to just have a different CSDEF then you can do it easily by using CSPACK command prompt directly as below:
Open command windows and locate the folder where you have your CSDEF/CSCFG and CSX folder related to your Windows Azure Project
Create multiple CSDEF depend on your minor changes
Be sure to have Windows Azure SDK in path to launch CS* commands
USE CSPACK command and pass parameters to use different CSDEF and Output CSPKG file something similar to as below:
cspack <ProjectName>\ServiceDefinitionOne.csdef /out:ProjectNameSame.csx /out:ProjectOne.cspkg /_AddMoreParams
cspack <ProjectName>\ServiceDefinitionTwo.csdef /out:ProjectNameSame.csx /out:ProjectTwo.cspkg /_AddMoreParams
More about CSPACK: http://msdn.microsoft.com/en-us/library/windowsazure/gg432988.aspx
As far as I know, you can't easily modify the .cspkg after it is created. I guess you probably technically could as the .cspkg is a zip file that follows a certain structure.
The question I'd ask is why? If it is to modify settings like VM role size (since that's defined in the .csdef file), then I think you have a couple of alternative approaches:
Create a seperate Windows Azure deployment project (.csproj) for each variation. Yes, I realize this can be a pain, but it does allow the Visual Studio tooling to work well. The minor pain may be worth it to have the easier to use tool support.
Run a configuration file transformation as part of the build process. Similiar to a web.config transform.
Personally, I go with the different .csproj approach. Mostly because I'm not a config file transformation ninja . . . yet. ;) This was the path of least resistance and it worked pretty well so far.
At the end of my Clean/Build, I wanted to always automatically copy the project folder into a zip for easy transfer. So I added this to my post build <target> in build.xml:
<zip zipfile="../project-xyz.zip" basedir=".." includes="project-xyz/**" excludes="*/dir/lib/**"/>
This works great on Windows, but on Linux, it removes any .hidden folders and all their children. I even tried
<zip zipfile="../project-xyz.zip" basedir=".." includes="project-xyz/**,project-xyz/.hidden/**" excludes="*/dir/lib/**"/>
and it still doesn't work.
What can I do to bring those files into the zip?
I am not opposed to detecting non-Windows environments and using <exec> on the zip command, though I am not sure how I would do that, and I am not sure I really want to, especially if there is a better way!
You can see what gets excluded by default from the zip by adding the following line in ant
<defaultexcludes echo="true"/>
And then use
<defaultexcludes add=.../>
and
<defaultexcludes remove=.../>
to customize what gets excluded by default.
Reference: Ant docs for DefaultExcludes
EDIT
You can also do
<zip defaultexcludes="no" .../>
Reference: Ant docs for Zip
As part of a content migration project, I am building content into a CMS on a weekly basis, and I use an Ant script to copy the content files to the build directory. Up until now, we've been wiping the CMS and reloading the whole 17,000-file set every time, which takes about 1.5 hours. But now that the content and the CMS customisations are more stable, we'd like to only upload the content files that have been modified since the previous week.
I can copy files modified since the last time I ran the Ant script using the <modified> selector:
<copy todir="changed" failonerror="no">
<fileset dir="output" includes="*.*">
<modified/>
</fileset>
</copy>
Which works very nicely. However, I would like to be able to load the files that have been modified since the last CMS build that took place on the server. So I was wondering if there was some way of using <modified>'s cache-based approach to only copy the files that have been modified since a given date/time like "17.00 last Thursday" instead of "last time this script was run".
I got the answer I was looking for on the Ant mailing list where Stefan Bodewig suggested using the update parameter on the modified selector. As I'm using Ant 1.7.1., I had to work around a bug that prevented its direct use as an attribute, but essentially, by setting it using a property set on the command line, I can update the cache whenever I do a production build, and leave the cache as it is when I do an intermediate test build.
Here is the code I ended up with (including workaround for 1.7.1.):
<copy todir="\content\Test\" includeEmptyDirs="false" failonerror="no">
<fileset dir="../Output">
<modified>
<param name="update" value="false"/>
</modified>
</fileset>
</copy>
Would the date selector do the job?