I have a project that publishes its jars to ivy. For code that is currently in development it publishes as 1.DEV.x. This has worked mostly well for keeping everyone integrating on track.
I have noticed the minor versions have no longer matched and I would like to match them back up. For example, some dependencies show a minor version of 60, while some show 10. In fact, they have completely stopped incrementing revisions at all. This is bad because now for projects to properly resolve, they must run a clean-ivy-cache command to pick up the changes.
Today, I cleared all 1.DEV.x dependencies from ivy by deleting all containing folders. There are a few dependencies that have started at minor version 6 (not sure why its not 0) and the rest at their usual number. The current problem is now the projects that depend on these can't seem to find them. For example, one dependency with minor version 6 says it found it at version 7, but when trying to download, throws an error because it isn't there. The work around is to create the folder, rename the dependencies, and re run the build.
I would like to have it start over at minor version 0, and would also like it to continue incrementing. I can't seem to find anywhere where that could be reset.
You need to clear the dependencies and the configuration. When you publish, look at the two sets of files being uploaded.. clear both of these.
Related
After a recent update (both Jenkins and Plug-ins) my Ivy Project settings can no longer be changed due to incompatible layouts (table to div change in a minor version update, from Jenkins 2.263 to 2.264). This broke every plugin that was involved in configuring projects, but went unnoticed for two months because our project settings haven't needed to change in quite a while, and the builds were still working fine in the meantime.
For reference, my build process is based on:
Ant for the build
Ivy for dependency resolution
Artifactory as a dependency repository
Subversion as a code repository (with Jenkins commit triggers)
Junit with Cobertura, Jmeter
FindBugs, CheckStyle, CLOC
Projects are based on Java and JavaDoc
I tried reverting to the earlier version of Jenkins, but this affected nearly every plugin, and I wasn't able to successfully revert to the plugin version combination from prior to the breaking update. After failing to revert the updates, I decided instead to plow forward in updating all of our 68 projects to accommodate the new plugin versions.
Unfortunately, I can't save any configuration changes to Ivy Projects. After trial and error, I've found that I can re-produce my builds using Freestyle Projects. However, Jenkins doesn't seem to offer any way to convert projects from one type to another. If I were to create new projects from scratch to replace my existing projects (all 68, including their dependencies and specific plugin settings), I would lose all of my previous build histories, including the build numbers (which carry over to our deployments) and our project metrics (which we use for performance evaluation). So, I don't want to lose all of that information.
How can I manually change an Ivy Project to a Freestyle Project?
I found a partial solution, but it doesn't seem to work for all projects.
Stop the Jenkins webapp (important).
For each Ivy Project that you want to convert to a Freestyle Project, rename the root element of jobs/[project]/config.xml from <hudson.ivy.IvyModuleSet plugin="ivy#2.1"> to <project> (don't forget to also change the closing tag at the end of the document from </hudson.ivy.IvyModuleSet> to </project>.
Restart Jenkins.
For most projects, I am then able to change the project configuration and save (importantly, Ant/Ivy-Artifactory Integration in a Freestyle Project is a feature-matched substitute for an Ivy Project).
However, three other projects still show up as Ivy Projects after changing the root element tag. What these projects had in common was that they all use the Performance Plugin. In order to finish converting these to Freestyle, I needed to additionally:
Disable the Performance Plugin
Restart Jenkins
Edit/Save the configuration for those projects as above.
Side effects and special considerations:
All of my build timestamps (prior to the change) are now listed as Dec 31, 1969 7:00 PM EDT, with a most recent build time as 50 yr. New build timestamps are correct. This likely was the result of no longer depending on the CloudBees plugin for build pipelines, which mapped build timestamps to build versions to avoid an old regression bug.
Every project immediately changed to red (Failed) on the dashboard, even though no builds had been attempted after the update, and the previous status was blue (Success) or yellow (Unstable). I suspect this is related to the above issue. After the next attempted build, whether successful or not, the status accurately reflects the build status.
No ability to use the Performance Plugin.
Several projects now show up as both an Upstream and Downstream Project, causing endless build cycles. There were three cases of this involving different combinations of projects, and in those cases, one or both projects needed to be removed from the build triggers. I suspect it had been this way for a while but for some reason the endless cycles only happen after the update.
I suddenly have a lot of "Unreadable Data" across all of my Jenkins projects. Unfortunately, discarding it is an all-or-nothing process (can't pick a single project to test). I backed up my jobs directory and clicked Discard, and to my surprise everything still works.
It looks like I'm back in business. My build numbers have been preserved, and the only noticeable side effect is the 50 year old builds. If I encounter any other issues resulting from these changes, I will update this answer.
The last time I deployed the project, the build worked perfectly.
In the meantime I have changed nothing that would affect the pip requirements, yet I get an error when building:
Could not find a version that matches Django<1.10,<1.10.999,<1.11,
<1.12,<1.9.999,<2,<2.0,==1.9.13,>1.3,>=1.11,>=1.3,>=1.4,>=1.4.10,
>=1.4.2,>=1.5,>=1.6,>=1.7,>=1.8
I get the same error when building the project locally with docker-compose build web.
What could be the problem?
The problem here is that although you may not have modified any requirements, the dependencies of a project can sometimes change on their own.
You may even have pinned all of your own requirements (which is generally a good idea) but that still won't help if one of them itself has an unpinned dependency.
Anywhere an unpinned dependency exists, you can run into this.
Here's an example. Suppose your requirements.in contains super-django==1.2.4. That's better than simply specifying super-django, as you won't be taken by surprised if a new, incompatible version of the Super Django package is released.
But suppose that in turn Super Django 1.2.4, in its requirements, lists:
Django==1.11
django-super-admin
If a new version of Django Super Admin is released, that requires say Django>=2.0, your next build will fail because of the mutually exclusive requirements.
To track down the culprit when you run into such a failure, you need to examine the build logs. You'll see there something like:
Could not find a version that matches Django==1.11,>=2.0 [etc].
So now you know to look back through the logs to find what is wanting to install Django>=2.0, and you'll find:
adding Django>=2.0
from django-super-admin==1.7.0
So now you know that it's django-super-admin==1.7.0 that is the key. Since you can't trust super-django to pin the correct version of django-super-admin, you'll have to do it yourself, by adding django-super-admin<1.7.0 to the requirements.in of your project.
There's more information about this at How to identify and resolve a dependency conflict.
You can also Pin all of your project’s Python dependencies to ensure this never happens again with any other dependency, though you sacrifice some flexibility for the guarantee.
Note: I am a member of the Divio team. This question is one that we see quite regularly via our support channels.
I've finally upgraded an old project from a folder of downloaded js-libs, which were committed to the repository, to bower. It works great, using a new library is great, upgrades are much easier, but - what if a package is broken?
In this specific case, there is a small bug in the library, which affects me hugely. A solution has been submitted via PR 2 months ago, but hasn't been merged yet. And even if it gets merged, it doesn't mean a new version will be published right after.
What is the best way to apply the fix myself, in a way, that I could switch back to the official package, whenever a new and fixed version has been published.
I see two options:
download the code (as I used to have it) and modify it locally + commit it into the repo
fork the original project, merge the change into the project and publish it as a new (temporary) bower package
1st solution seems stupid and 2nd a bit too complicated just to change one line of code. In either case I'd need to keep my eyes opened if something has changed and switch back and forth manually.
Are those the only two options, or am I missing something?
I've been tasked with setting up a new Team Foundation/Build server at my company, with which we'll be starting a new project. Nobody here currently has experience with TFS, so I'm learning all of this on my own. Everything is working so far; The server's been set up, the Repository and Team Project has been created, the Build Server has been created, and I've created a simple hello world application to verify the source control and Continuous Integration builds (on the build server) run properly.
However, I'm having a problem setting up the automatic versioning. I've installed the TfsVersioning project, and it's working fine; I'm able to define a format for my assembly versions. I haven't yet decided what format I'll use; probably something like Major.Minor.Changeset.Revision (I'm aware of the potential problem regarding using the changeset number in the assembly version, so I may decide to switch to Major.Minor.Julian.Revision before we begin development).
The problem:
I don't want assemblies to have new file versions if their source code has NOT changed since the last build. With a continuous Integration build this isn't a problem, as the build server will only grab the source files that have changed, causing an incremental build which produces only updated modules; the existing unchanged modules won't be built, so their version will remain unchanged.
If I set up a nightly build, I'll want to clean the workspace and perform a Build-All. However, this means that ALL assemblies will have new version (assuming the Assembly File Version includes the build number).
A solution?
This has prompted me to consider using the latest changeset number in the Assembly File Version. This way, if nothing has been committed between two successive Build-Alls, the versions won't be incremented. However, this would mean that a change and commit to a single file would force a version increment on ALL assemblies.
I'm looking for one of two things:
A way to only increment Assembly Version Numbers if their source/dependencies have changed since the last build. Successive Build-Alls should not cause changes in version numbers.
OR
A way for testers and non-developers to be able to tell version W.X.Y.Z and version W.X.Y.Z+1 of assembly 'Foo' are identical, even though they have differing file versions.
I've probably read about 20 articles on the subject, and nobody (except this guy) seem to address the issue. If what I'm asking for isn't common practice in the Team Foundation ALM, how do I address the second bullet point above?
Thanks for your time!
This is something I did in the past. The solution has two critical points:
You must use an incremental build, i.e. Clean Workspace = None
The change to AssemblyInfo.cs must be computed at each project
This latter is the most complex and I will just draft the solution here.
In the custom MSBuild properties use CustomAfterMicrosoftCommonTargets to inject an hook in normal Visual Studio compile
/property:CustomAfterMicrosoftCommonTargets=custom.proj
Also forward a value for the version
/property:BuildNumber=1.2.3.4
In custom.proj redefine the target BeforeCompile to something similar
<Target Name="BeforeCompile"
Inputs="$(MSBuildAllProjects);
#(Compile);
#(_CoreCompileResourceInputs);
$(ApplicationIcon);
$(AssemblyOriginatorKeyFile);
#(ReferencePath);
#(CompiledLicenseFile);
#(EmbeddedDocumentation);
$(Win32Resource);
$(Win32Manifest);
#(CustomAdditionalCompileInputs)"
Outputs="#(DocFileItem);
#(IntermediateAssembly);
#(_DebugSymbolsIntermediatePath);
$(NonExistentFile);
#(CustomAdditionalCompileOutputs)"
Condition="'$(BuildNumber)'!=''">
<Message Text="*TRACE* BuildNumber: $(BuildNumber)"/>
<MyTasksThatReplaceAssemblyVersion
BuildNumber="$(BuildNumber)"
File="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"/>
</Target>
You need to have a task for replacing the AssemblyFileVersion in the AssemblyInfo.cs source. MSBuild Extension Pack has an AssemblyInfo task for this purpose.
I posted the full details at my blog here, here and here.
(I don't really care if it's my fault but rather why things are happening, of course...)
I have a rails site in SVN on a remote server. On my local copy I do a switch (svn switch http://whatever/branch .), and then things are totally bizarre and the site doesn't work. I finally track it down and it turns out that part of the build (particularly, the app/config directory) is pointing to the wrong branch. Please note:
I never switch using anything other than the SVN command line
I only switch at the root of the installation
I always switch as root (sudo -s) and I'm sure that the permissions were set correctly on the whole tree (chmod -R 777)
Any ideas on how part of the working directory could end up pointing to the wrong place? In my memory, this is not the first time that some sub of the working directory is pointing to the wrong place... why would this happen?
There is a whole section about switch problems in the official Subversion FAQ. It says:
In some cases where there are
unversioned (and maybe ignored) items
in the working copy, svn switch can
get an error. The switch stops,
leaving the working copy
half-switched.
Their advice is to only switch from a clean working copy.
Another thing is Mixed Revision Working Copies.
Basically this means that the files in your working copy can be (and normally are) from
different revisions.
Here is what the SVN Red Book has to say about this (emphasis by me):
For example, suppose you have a
working copy entirely at revision 10.
You edit the file foo.html and then
perform an svn commit, which creates
revision 15 in the repository. After
the commit succeeds, many new users
would expect the working copy to be
entirely at revision 15, but that's
not the case! Any number of changes
might have happened in the repository
between revisions 10 and 15. The
client knows nothing of those changes
in the repository, since you haven't
yet run svn update, and svn commit
doesn't pull down new changes. If, on
the other hand, svn commit were to
automatically download the newest
changes, then it would be possible to
set the entire working copy to
revision 15—but then we'd be breaking
the fundamental rule of “push” and
“pull” remaining separate actions.
Therefore the only safe thing the
Subversion client can do is mark the
one file—foo.html—as being at revision
15. The rest of the working copy remains at revision 10. Only by
running svn update can the latest
changes be downloaded, and the whole
working copy be marked as revision 15.
Excuse me if you know what you're doing, but it sounds like you aren't. (Or the question isn't clear). If you include the results of svn status from the relevant directories, we could get farther.
svn switch
(svn help switch)
is for switching repositories, which shouldn't part of a common workflow.