We are using Gerrit 2.12 with MySQL DB. There is one review open for a while but when I try to access it from Gerrit UI, I get following error.
The page you requested was not found, or you do not have permission to view this page.
I am logged into the UI and my account have administrative capabilities.I can see the entry of the change in changes table in data base. Should reindexing solve the problem? I am more curious about what was the trigger for disappearance of change in UI.
I had the same problem. I have verified if the changes were there in the repository by cloning the corresponding change under refs/changes branch.
As the documentation says, When a commit is pushed for review, Gerrit stores it in a staging area which is a branch in the special refs/changes/ namespace. A change ref has the format refs/changes/XX/YYYY/ZZ where YYYY is the numeric change number, ZZ is the patch set number and XX is the last two digits of the numeric change number, e.g. refs/changes/20/884120/1. Understanding the format of this ref is not required for working with Gerrit.
Using the change ref, git clients can fetch the corresponding commit, e.g. for local verification.
git clone <URL>
cd <reponame>
git fetch https://yourhostname/reponame refs/changes/16/261016/1 && git checkout FETCH_HEAD
If you find the fetch to be happening successful, it means that the change is present and therefore a full reindex as the appropriate user should fix.
su gerrit -c "java -jar gerrit.war reindex"
PS. Online reindex did not help in my case. I had to do a full offline reindex as above.
Related
In an effort to boost code reviews, I am looking to send a daily/weekly/monthly/some_regular_interval report of changes from mercurial? I figure that if a person does not have to go and find the changes, but they are instead brought to the person, then that should be a step in the right direction. However, I did not see anything already out there. (We use mercurial with TortoiseHG and Jenkins for the automated build in case any of those tools might help?)
What I am looking for:
MUST HAVE
commit message
list of files that changed
NICE TO HAVE
changeset guid
name of person who did the commit
some means to see what changed on each file (probably best via a URL or else the email could become overloaded)
You don't state what OS you are using. I am assuming Windows since you are using TortoiseHG.
On Linux (or other UNIX-based OS) you can create a cron that runs once a week/month/whatever. The following simple script satisfies most of your requirements on my Linux machine:
LOG_DATE=`date -d "1 week ago" +"%Y-%m-%d 00:00:00"`
hg log -d ">$LOG_DATE"
If you use Mercurial templates you can get exactly what you want. You can construct a URL using the changeset ID to point to a Mercurial web-server.
Would the notify extension work? You can configure this on a designated master repository so that emails with a summary of the changes (you can customise the template to include the short form of the hash, the user name, the commit message) along with URLs to the individual changesets are sent out to people whenever changese are pushed to the master repository.
I'm using Google code and Mercurial for a small project javaclass-rb. I cloned the repository using HTTPS. My .hg/hgrc contains
[paths]
default = https://javaclass-rb.googlecode.com/hg/
From time to time Google Code has a different fingerprint (most likely to the clustering of service). When I want to pull (with hg 1.8.4), I get
E:\Develop\JavaClass>hg pull -u
abort: invalid certificate for javaclass-rb.googlecode.com with fingerprint 28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Then I have to change my ~/.hgrc file and update the hostfingerprintssection to contain the new fingerprint:
[hostfingerprints]
javaclass-rb.googlecode.com = 28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Then everything works fine again, until next time. Now this gets annoying as I did it ten times already, approx. once a month, and have to do it on several machines (desktop, laptop, work pc etc.)...
34:4b:90:e7:e3:36:81:0d:52:1f:10:c0:4c:98:66:90:4a:9e:05:c9
6e:a8:09:6a:42:60:d7:81:f7:04:b8:0f:5d:1e:ac:b3:58:db:7e:da
89:6d:fb:e5:4a:7e:72:91:db:0b:ee:72:9f:60:a7:29:65:fd:e1:10
da:b3:df:aa:55:73:ac:65:04:70:78:8e:ed:dd:a9:be:40:a8:64:81
a9:be:c0:4a:da:1c:eb:4c:31:9d:78:27:48:99:f4:9c:9a:e8:53:c8
ed:19:7c:b9:a3:48:27:93:72:74:43:db:26:40:af:e0:7a:90:1c:97
28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Do you know a way to configure Mercurial to ignore the fingerprints or some other way I get rid of this annoyance?
Answer
tonfa led me on the right track. Mercurial is checking also OS certificates. Originally I had to fall back to fingerprints because Googlecode certiicate is not valid for subdomains:
The certificate is only valid for the following names:
*.googlecode.com , *.u.googlecode.com , googlecode.com , *.codespot.com , *.googlesource.com , googlesource.com
1) I removed the fingerprints from .hgrc, then the top domain javaclass-rb.googlecode.com worked again, because it is matched by *.googlecode.com.
2) Subdomains have to be cloned with another name, see Google support.
Ignoring the fingerprints and not verifying the signature is a very bad idea.
You should follow the instructions at https://www.mercurial-scm.org/wiki/CACertificates (basically a recent version of TortoiseHg should be already correctly configured).
Try the command hg pull --insecure.
I have kind of an interesting problem...
So I'm trying to run a build every time I see a change on a directory in my SCM in Hudson. However, I don't need to pull the directory to run my script. Is there any way to check if there's a change in a directory, but don't pull it?
In addition, there is another directory which I do need to pull from Hudson at the same time. So basically I want something like:
On change of directory A or B:
pull directory B only
run script
I was told there was functionality like this in Hudson, but I can't find it. Any suggestions? Thanks for the help!
In case anyone is interested, I was able to accomplish this with just Hudson and Perforce.
When using Perforce as the SCM (don't know about the others) there is a 'Use View Mask' checkbox. Checking that give you the ability to choose which directories/files in Perforce to poll without actually pulling those files. For example, I had in my view:
//depot/my_script
I didn't want my script to run automatically when I had a new version, so I put it int o the "Poll Exclude File(s) text box:
//depot/my_script
Which pulls the latest version of my script. Then I checked the Use View Mask checkbox and put:
//depot/my_code_to_compile/
into the View Mask box.
To make Perforce poll for changes, I just checked the "Poll SCM" in build triggers and then made it check every minute. (by inserting "* * * * *" into the Scheduler box)
So to sum up, with the variables set as above, my Hudson job had the following behavior:
check for changes every minute
On changes to //depot/my_code_to_compile/, the Hudson job will run
On changes to //depot/my_script, nothing will happen
The job will pull changes to my_script, but will download nothing from //depot/my_code_to_compile/.
I think you need to install the FSTrigger Plugin for this functionality. To what the wiki pages show this is supported in Jenkins, I am not sure about Hudson compatibility.
I have a "central" repository that I want to ensure that no one pushes changes in to with a wrong user name.
But I can not figure out how to make a hook that tests the user name against a positive list. I have found in the Mercurial API a ctx.user() call that seems to be what I want to test my positive list against.
Also the hook could be a precommit hook that is distributed as part of the repository clone or it could be a hook on the central repository as a pre-incoming or something like that.
Any help or pointers would be greatly appreciated.
I have posted two functional examples on Bitbucket. Both examples are for searching a commit message for some specifically formatted text (like an issue tracked case ID), but could be easily modified to check a user against a list of valid users.
The first example is actually a Mercurial extension that wraps the 'commit' command. If it fails to find the appropriate text (or valid user in your case), it will prevent the commit from occurring at all. You can enable this in your .hgrc file by adding these lines:
[extensions]
someName = path/to/script/commit-msg-check.py
The second example uses a in-process pretxncommit hook, which runs between when the commit has been made, but before it becomes permanent. If this check fails it will automatically roll back the commit. You can enable this in your .hgrc file by adding these lines (assuming you kept the same file/function names):
[hooks]
pretxncommit.example = python:commit-msg-check-hook.CheckForIssueRecord
You can execute any Python code you like inside of these hooks, so user validation could be done in many ways.
Thanks for the examples dls.
In the end I decided to run it as a pretxnchangegroup hook and then use the hg log and grep to test the author field of the commits:
[hooks]
pretxnchangegroup.usercheck = hg log --template '{author}\n' -r \
$HG_NODE: | grep -qe 'user1\|user2\|etc'
It does of course not provide a very good feedback other than usercheck failed. But I think it is good enough for now.
I am trying to do "continuous integration" with TeamCity. I would like to label my builds in a incremental way and the GUID provided by the VCS is not as usefull as a simple increasing number. I would like the number to actually match the revision in number in Mercurial.
My state of affairs:
Mercurial info:
I would like the build to be labeled 0.0.12 rather than the GUID.
Would someone be so kind and save me hours of trying to figure this out ?
As Lasse V. Karlsen mentioned those numerical revision numbers are local-clone specific and can be different for each clone. They're really not suitable for versioning -- you could reclone the same repo and get different revision numbers.
At the very least include the node id also creating something like 0.0.12-6ec760554f2b then you still get sortable release artifacts but are still firmly identifying your release.
If you're using numeric tags to tag releases there's a particularly nice option:
% hg log -r tip --template '{latesttag}.{latesttagdistance}'
which, if the most recent tag on that clone was called 1.0.1 and was 84 commits ago gives a value like:
1.0.1.84
Since you can have different heads that are 84 commits away from a tag in different repos you should still probably include the node id like:
% hg log -r tip --template '{latesttag}.{latesttagdistance}-{node|short}'
giving:
1.0.1.84-ec760554f2b
which makes a great version string.
The best and easiest way to see rev. number in TeamCity build number is to use Build Script Interaction with TeamCity. Namely, it has a possibility to set Build Number.
So, add to your project a new very first build step Command Line with following Command Executable
for /f %%i in ('c:\tortoisehg\hg id -n') do echo ##teamcity[buildNumber '%%i']
And you will get the Mercurial revision number as a label for your every build.
Of course you can change the command in quotes to anything you wish.
I believe my answer is way more correct than the accepted one.
EDIT:
Also you can do the same via MSBuild task rather than Command Executable. Have a MSBuild project file with following code, setup TeamCity to run it as first step, and it will alter its global variable buildNumber:
<Message Text="##teamcity[buildNumber '$(CurrentVersion)']" Importance="High" />
Where CurrentVersion is a string containing full version (for example "1.0.56.20931").
hg id produces the hash (6ec760554f2b), hg id -n produces the local revision number (12).
(Note this is an answer purely from the hg side, how you then get that into TeamCity, I don't know, as I've never used it.)
I managed to use it in Teamcity using a workaround:
<Exec Command="hg log -r tip --template {latesttag}.{latesttagdistance} > $(BuildAgentTempDir)\version.txt"/>
<ReadLinesFromFile File="$(BuildAgentTempDir)\version.txt">
<Output TaskParameter="Lines" ItemName="versionInfo"/>
</ReadLinesFromFile>
<TeamCitySetBuildNumber BuildNumber="#(versionInfo)-{build.number}" />
If you see the MSBuild task "TeamCitySetBuildNumber" I'm using the "{build.number}" variable because it substitutes this with what you set in the build number originally. I used %build.vcs.number% in my original settings (in the Web UI) and the result is just what Ry4an wrote above!
Hope it works for you!
When I used to use Subversion I used to do something similar in TeamCity. The format was:
{Major}.{Minor}.{TeamCity Build No.}.{Subversion Revision No.}
This allowed me to look at an assembly and see which build it came from on TeamCity and the revision number from subversion.
I have now moved to Git which has put me in the same situation as you. After playing with various ideas I have come to the conclusion that I don't actually need the revision, the build is good enough. Because TeamCity is such a powerful tool, all you need is the build number, given the build number you can look at the build history and determine the revision from that.
{Major}.{Minor}.{Macro}.{TeamCity Build No.}
Additionally you can get TeamCity to label your repository with the build number allowing you to look up a given build in your source control.
When providing your build number with numeral mercurial revision, you must be aware, that those numbers are clone-specific and can differ from clone to clone.
In our project we had the same issue. We're using TeamCity 7.1.1. We solved it in the following way:
Add Command line build step to your configuration.
Make this build step run first.
In the build step properties select "Run: 'Executable with parameters'"
Add the following text to Command Executable:
for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%%i']
Save changes.
You can also use previously generated build number when performing step 3.
Example:
for /f %%i in ('hg id -n') do echo ##teamcity[buildNumber '%system.build.number%.%%i']
You can use this to make build counter present in your build number.
Read this to get more information!
Remember that teamcity compiles configurations build number before build starts and the correct build number will appear only after your build step will finish its job. That's why, in some cases (f.e. inserting your mercurial revision into artifact's name) you should define build number's value in preceding configuration and refer to it.
Example:
%dep.bt82.build.number%
Read this to get more information!