We have a problem where despite no code changes SCM is triggering a build. SCM polls for changes every 15 minutes and should only trigger a build if changes are found.
Here are a few examples of consecutive SCM polling log.
Started on Nov 15, 2013 11:47:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.23 sec
Changes found
Started on Nov 15, 2013 11:17:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.22 sec
Changes found
Started on Nov 15, 2013 11:02:14 AM
Using strategy: Default
[poll] Last Built Revision: Revision 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 (origin/develop)
Done. Took 0.2 sec
Changes found
As you can see the revision is the same and matches that of
Git Build Data
Revision: 08f48cc5675ae0126256cf24d6ee74c8fc9d7b30 origin/develop
These jobs behaved as expected until a few days ago. There is nothing that we're aware that has changed about our environment to cause this.
I upgraded to the latest version of Jenkins (1.539) and installed plug-ins last night in a effort to resolve this but the behavior continues.
I just ran into Jenkins continuously building due to an SCM change, even when there was no change, and polling was not even turned on. This may be different from your scenario but I figured it may still help to share my solution.
Out project is configured to build using the branch specifier */integration just like all of our other integration builds. However, after looking at all of the branches on our origin git repo, I saw that there are two branches that matched the */integration specifier. It looks like a developer must have erroneously pushed to a new branch with a very similar name:
$git branch --remote | grep integration
origin/integration
origin/origin/integration
The solution that fixed this issue for me was to specify the branch fully, using refs/heads/integration. I assume it would also work to simply delete the duplicate offending branch, but by specifying the branch exactly I can avoid running into the same problem in the future.
I'm not sure this is the same cause for your problem but this is what worked for me, and hopefully will work for someone else in this situation.
Seems to be reproducible with latest Jenkins GIT plugin version 2.0.
Downgrade to version 1.x may fix the problem. Though you should also revert Jenkins configuration from older backup as GIT plugin version 1.x seems to be not working with new 2.0 configuration scheme.
This thread suggests to enable "Fast remote polling" as a workaround. In version 2.0 it's called "Force polling using workspace" I think.
Reference to Jenkins issue: https://issues.jenkins-ci.org/browse/JENKINS-20767
I was experiencing this same issue today. It started happening when I added the "Delete workspace when build is done" publish task. I removed that task and it seemed to resolve the issue.
I ran into the same problem.
What fixed it for me is noticing that the Git Polling Log looked like this:
Started on [date]
Using strategy: Default
[poll] Last Built Revision: Revision [commit#] (origin/develop)
[...]
Found 12 remote heads on ssh://[...]/repo.git
[poll] Latest remote head revision on refs/heads/feature/foo is: [commit#] - already built by 1414
[poll] Latest remote head revision on refs/heads/feature/bar is: [commit#] - already built by 2365
[poll] Latest remote head revision on refs/heads/feature/baz is: [commit#] - already built by 1489
[poll] Latest remote head revision on refs/heads/feature/qux is: [commit#] - already built by 1413
[poll] Latest remote head revision on refs/heads/develop is: [commit#] - already built by 2368
[poll] Latest remote head revision on refs/heads/master is: [commit#]
Done. Took 0.16 sec
Changes found
Notice that the line for master doesn't say 'already built'. I built the master branch and that fixed the problem.
Be carefull with svn redirections, in my case i had the same case Jenkins could not detect if svn has no changes and allways was triggering.
The problem was that in my jenkins svn configuration had this url:
https://xxxx.yyy.es:443/svn/myproject/trunk and its redirect to
http://xxxx.yyy.es:8008/svn/myproject/trunk (i dont know why)
Jenkins had to be configured with the last URL in order to detect the svn changes properly.
This is my issue Resolved.
http://antuansoft.blogspot.com.es/2014/10/jenkins-pool-smc-always-detect-changes.html
Removing the cleanup step at the end of the pipeline did the trick for me:
cleanup {
cleanWs()
}
There is another scenario in which this happens, which is if the repository was transferred.
I solved it by manually modifying the git URLs, which were inside the cache files (/caches directory in Jenkins home folder)
Related
Using Win7 and TortoiseSVN, I created a plugin, followed the directions for first committing trunk, then created a branch/tag at /tags/x.y.z.
Except I forgot to update the version number at /my-plugin/trunk/my-plugin.php before I committed trunk and tagged the new revision.
The revision shows up in the plugin tags and as an alternative version -- but not the current stable version on wordpress.org/plugins/my-plugin/. Wordpress.org doesn't recognize it as the current stable version, even though I wrote it as such in readme.txt, perhaps because it still has the old version number at /my-plugin/trunk/my-plugin.php and /my-plugin/tags/x.y.z/my-plugin.php.
I want to either
a. delete the bad revision at /my-plugin/tags/x.y.z so I can recreate it correctly, or
b. edit/update the bad revision at /my-plugin/tags/x.y.z.
I tried switching to /my-plugin/tags/x.y.z so I could merge trunk to x.y.z, but I got this message:
Switch E:\subversion\wordpress plugins public\my-plugin to http://plugins.svn.wordpress.org/my-plugin/tags/x.y.z, Revision HEAD
'http://plugins.svn.wordpress.org/my-plugin/tags/x.y.z' shares no common ancestry with 'E:\subversion\wordpress plugins public\my-plugin'
What did I do wrong, and how can I fix it?
Easy way:
checkout tag
fix version number
commit
When I commit a sizable number of files (200 files) through GitHub for Desktop, it just sits there for a very long time (>10 minutes). It does eventually complete.
Scrolling through the debug log doesn't seem to show anything out of place.
This seems to be a recent development, as the previous Github for Windows did not seem to have this issue.
I'm currently on version The Last Free Monad (3.0.5.2) a0622a5, and my git version is 1.9.5.github.0
Any ideas?
Upgrading to the latest version of Git resolved the issue.
The issue with GitHub Desktop is that it includes its own version of git for windows, and you cannot update/upgrade it. I tried before and it didn't work.
But it is also true that since Nov 2015, GitHub Desktop finally went from an old 1.9.5 version to a 2.5+ version, which, as noted by the OP, improves the situation.
Note that you can have both GitHub Desktop and git for Windows (with different versions).
Here is the context:
I am using egit within Eclipse
I made a number of commits that I have not pushed to the remote repository
I suddenly notice a bug with my app that wasn't there before
How can I quickly update my working directory with earlier git commits until I find the first commit that introduced the bug? How do I then get back to my latest local commit?
I used hard git resets to do this recently and would have lost my last set of git commits if I hadn't found this answer so there must be another, safer way to achieve the same result.
I am running into a bug in my latest version of the code and want to go back in time until the bug no longer shows up.
That is called git bisect, and is not implemented in Egit.
You should consider using git in command-line, in order to launch a bisect session.
I just figured out the answer to my own question.
It's actually quite simple:
Do git checkout of earlier versions until identifying the last version that does not exhibit the bug and the first one that does
Then do a git switch to the master version to go back to the latest committed version
The checkouts are not intended to make further changes to the code but are quick and useful for updating the working directory without messing with the git directory, which is all what's needed to quickly pin-point the appearance of a new bug in the git tree.
I'm using subclipse to merge changes from the trunk into a branch and during the "best practices" step, there's a notification that the working copy is not at a single revision. None of the files or folders in the package explorer have the dirty indicator and (having been through this before) even after doing an update, none of the version numbers appear to have changed. What specifically is subclipse looking at to generate this notification? Is there something I can also run from the command line to corroborate this?
It basically means you have a "Mixed Revision Working Copy" which is very normal and common. If you Google it you will find a lot of explanations. A blog post I wrote many years ago is the top hit:
http://markphip.blogspot.com/2006/12/mixed-revision-working-copies.html
Subversion merge works a lot better if you have your working copy at a single uniform revision. So just run update. The merge wizard will do this for you if you let it.
Outside subclipse, in pure Subversion terms:
You WC may be in Clean state (no local modification), but - in Mixed. Mixed Working Copy will appear, when part of tree updated to revision, different from "Main"
Step to reproduce
svn co http://mayorat.ursinecorner.ru:8088/svn/Hello/
A Hello\trunk
...
Checked out revision 34.
cd trunk
svn up -r 30
Updating '.':
...
Updated to revision 30.
cd ..\..
subwcrev Hello
SubWCRev: 'z:\Hello'
Last committed at revision 28
Mixed revision range 30:34
"Mixed revision range" is warning for you and for your case. I can't recall can this check and how be done with pure svn client: always use subwcrev in build-tasks
For clean Working Copy (svn up in trunk done) subwcrev output
subwcrev Hello
SubWCRev: 'z:\Hello'
Last committed at revision 34
Updated to revision 34
SubWCRev is part of TortoiseSVN
I just opened up a project I last worked on two weeks ago and discovered that my working version is several revisions behind (using Mercurial via Bitbucket). The latest compiled assemblies on my dev machine are 100% up-to-date, but my local and remote code repositories are missing all the new code, which I compiled on my dev machine into the latest assemblies.
Disassembling the latest compile (a month old) using Red Gate's .NET Reflector, I can see all my newest code, but none of that is now anywhere to be found on my dev machine, or in any of my repositories. It's like all my code went back to the future. Is it possible I inadvertently reverted and overrode some code from my remote repository and there is no trail of it?
I must not have committed my latest changes, but surely these should still be in my working copy? I am unaware of any system roll-backs. I run Visual Studio 2010 on my Windows 7 dev box and I am sure this is not Mercurial's fault, but is there some functionality I am not aware of? How is this possible?
Not-committing is always a bad idea, committing is how you say "this is something" not "this is finished".
What is the output of hg summary? Is it possible you've hg updated to a past revision -- if so all the new stuff is still in the repo, just not the working directory. Mercurial never throws away committed changes, and only gets rid of uncommitted changes if you use an option like --clean on update. If you did hg revert you'll have .orig backup files unless you did a --no-backup.
In brief, Mercurial won't throw away changes unless you work very hard at it, so either they're still there or it was something external.