Yesterday I've upgraded my Gitlab installation from 5.3 to 6.0 (technically from 5.3 to 5.4 and 5.4 to 6.0), and I can't display Network and other Graphs since then.
On the network page it seems some Javascript is not loaded, as I got a 'Network is not defined' error. Graphs seems to be a different issue, but I can't find anything in the logs.
Is it a bug or I did something wrong?
Both functions were working fine before the upgrade.
Try to precompile your assets:
sudo service gitlab stop
sudo -u git -H bundle exec rake assets:precompile RAILS_ENV=production
sudo service gitlab start
This seems to be a bug in GitLab. It breaks when it encounters a commit that doesn't change any files, such as when creating a branch.
It is in the issue tracker as issue #4867 and has been fixed in master.
Can you try running
bundle exec rake cache:clear RAILS_ENV=production
as per https://github.com/gitlabhq/gitlabhq/issues/4874
Related
I've done a fresh installation of Jenkins 2.14 on Debian (apt-get install jenkins). Installation is correct, proxy is well configured.
But when I try to create new Job (New item), I've got an empty page.
I'm an administrator with all rights so I guess it is not a problem with rigths management.
There is no errors in logs even if I set the log level to all.
Any clues will be greatly appreciated.
EDIT : I try with firefox and Chrome. Same result.
EDIT2 : I try with 2.13, 2.10, 2.3 without success. When I came back to 1.656 the new Job widows is displayed normally.
Jean-Marc
I was facing the same issue when I upgraded from 1.5 to 2.66 . After a little research I got my issue resolved. what I did is just upgraded the plug in external monitor job plug in to latest version 1.7 as of now.
References : https://issues.jenkins-ci.org/browse/JENKINS-36875
https://issues.jenkins-ci.org/browse/JENKINS-36875
https://wiki.jenkins.io/display/JENKINS/Build+Environment+Plugin
Running a TeamCity build agent to run NUnit tests on Ubuntu 14.04 LTC with the latest build of mono appears to have some dependency issues that I cant for the life of me solve.
I have followed the following installation steps
Mono Installation Steps for 4.0.1
Team City Build Agent
When the TC Build Agent starts the NUnit step, it simply fails, and looking at the logs shows it executes
/usr/bin/mono-sgen /home/ubuntu/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe
which promptly returns with
Corlib not in sync with this runtime: expected corlib version 117, found 111.
Loaded from: /usr/lib/mono/4.0/mscorlib.dll
Download a newer corlib or a newer runtime at http://www.mono-project.com/download.
Is there any possible way to get this to work? I have tried removing all the pieces and re-installing again and even installing a older version of mono build but to no avail.
The TC connection appears to work and I can manually invoke and call mono on its own and even nunit-console however this .exe build provided by TC seems to have be stumped as linux non-expert.
Please save me from dependency hell!!
Edit: I ended up just solving my problem by installing nunit-console and enabling the XML Report processing build feature rather than play around with the corelib files and break something else.
This is a Mono bug, see https://bugzilla.xamarin.com/show_bug.cgi?id=34675.
The problem is that Mono moved to providing the 4.0 assemblies, including mscorlib.dll, only in form of reference assemblies. They contain only metadata and are intended for the compiler. Normally applications just use the newest version automatically.
The loader code in Mono however wasn't updated to bind forward an explicit runtime version of v4.0.20506 or v4.0.30128 which TeamCity is using in their .exe.config files to the latest version. The runtime instead tries to load mscorlib.dll from the 4.0 directory and bails as the version is too old (it's from the time the reference assemblies were generated).
As a workaround, you can edit <build agent
installdir>/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe.config (and other .exe.config files)
and remove the following lines:
<supportedRuntime version="v4.0.20506"/>
<supportedRuntime version="v4.0.30128"/>
This might stop working once TeamCity decides to update the plugin though.
Replacing the mscorlib version is only asking for trouble - i.e. TypeLoadException's and friends are waiting around the corner to get you.
What I did was replace the Teamcity build step with a manual invocation of the TC NunitLauncher, but forcing it to use Mono 4.5:
mono --runtime=4.5 /Applications/buildAgent/plugins/dotnetPlugin/bin/JetBrains.BuildServer.NUnitLauncher.exe v4.0 MSIL NUnit-2.6.3 $(find **/bin/Release/*Tests.dll | paste -sd ";" -)
The invocation uses some shell trickery to find all assemblies I'm interested in using a wildcard, but other than that should be straightforward to understand.
It would be nice if Mono fixed their broken 4.0 runtime. Anyone already reported it on https://bugzilla.xamarin.com/ ?
This is how I worked around it : (note my mono is in /opt/mono)
$ cd /opt/mono/lib/mono
$ sudo mv 4.0 __4.0
$ sudo ln -s 4.5 4.0
i.e get rid of the 4.0 folder and symlink the 4.5 to be 4.0
This is something of a hack but it got me up and running until a proper fix surfaces!
Steve
I had this problem on my Raspberry Pi after compiling 4.0.2 but it was loading from /4.5/
This got me going:
sudo mv /usr/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5/_old_mscorlib.dll
sudo cp /opt/mono-4.0.2/lib/mono/4.5/mscorlib.dll /usr/lib/mono/4.5
I'm trying to build a Yocto image.
I'm running Ubuntu 12.04. I've installed the packages the link above recommends (and more)
I cloned the poky git repository, and checked out the daisy-11.0.0 tag.
conf/local.conf has MACHINE=qemux86, nearly all other settings are default.
I tweaked # of threads for bitbake and make.
bitbake -k core-image-minimal
I get the following error during the do_configure task of libusb1_1.0.18.bb:
configure: error: "udev support requested but libudev not installed"
libudev-dev is installed.
This seems strange to me because I'm using a plain vanilla no frills setup.
Does anyone know how to resolve this configure error?
I'm not 100% sure this is on-topic for SO. Please direct me to the proper place if so before closing.
You should just do a repo sync, it has been solved and pushed today (20 may 2014)
I got the exact same problem but in a slightly different environment. I’m just sharing this answer in case it helps you solve your problems.
Anyway, I am running Ubuntu 14.04, and I checked out the latest from git://github.com/openembedded/oe-core.git. I started a build but got the exact same problem. Just like you, I get the following error during the do_configure task of libusb1_1.0.18.bb:
configure: error: "udev support requested but libudev not installed"
So I checked the git logs and noticed that that particular recipe was modified on May 15, which was a day before my checkout. I decided to pull out those changes (by checking out the previous commit) and rebuilt the image. It succeeded, which makes me think that update may have broken the build.
I'm getting error - One or more Dlls have change stopping after cloning in git for 1 hour. We have been running cc.net with hg and now trying to migrate to git.
I'm getting this error , not sure how else to proceed.
this is due to the fact that the first integration with git will get all mods :-(
download the latest dev release, it has been fixed.
The 1.8.5 version of CCNet will be out soon.
http://build.nauck-it.de/download/CruiseControl.NET-dev/
When upgrading my very old version of gitlab(4.0.1) to 6.0, after running the rails migrate script, the gitlabhq_production database just gets wiped out, leaving only tables, but no data in them. The command I am using is:
sudo -u git -H bundle exec rake db:migrate RAILS_ENV=production
I thought of checking out the upgrade scripts from every major revision and running them, but I figured this would be handled directly in the most recent script. Before running the above script, I also made sure I created a git user(both in db and on the OS), and reassigned table ownership to the git user.
Does anyone have any tips on how this could be solved?
It is best to:
restore your database (assuming you did a backup before attempting the migration)
follow the migration guides from 4.2 to 5.0, and then from 5.0 to 5.X, then 6.0
The most recent scripts will be able to automate the upgrade process only from 6.x to 6.y.