How do I configure Hudson/Jenkins (we're still using Hudson) to build all branches with the mercurial plugin? I have seen that we can create separate jobs/etc for specific branches, but we branch often enough that it would be good to just build all branches.
The only way I can think of (and I haven't tried it) is to have our build script [executed by Hudson on the slave] somehow figure out which branch is the latest commit and then hg update -r itself, rather than the mercurial plugin doing it.
I would love to find out a more elegant/correct way to do this!
I've also been looking for this support in the Jenkins Mercurial plugin (partly because it's supported by its Git plugin) but the following Jenkins tickets seem to indicate that this is yet not implemented:
https://issues.jenkins-ci.org/browse/JENKINS-11102
https://issues.jenkins-ci.org/browse/JENKINS-10558
One option if you have branches that are used regularly (ie, named branches for milestones or developers) is to create copies of your master build and simply point it to that branch.
For example on my team's build server we have production ('default' branch) and development ('dev' branch). Our builds are run by feeding the branch name as a parameter to the build script (so it's a simple, one-field change from a copy of the main job).
Obviously this won't scale beyond a handful of branches, but it might be enough for your needs.
Related
We collaborate with a third party (contractor) using our "master" mercurial repo on a project for a client. It appears we get a very cluttered commit history (including trail and errors). We'd like to hide these details from the client (i.e. not reveal the whole commit history). However, at the same time, we would like to use the repo to deliver our results to the client (in a orderly and more "condensed" form).
Is there a recommend work flow (and tooling/hg commands) that suit this purpose?
There's no good/easy way to do this, but there are plenty of bad/hard ways to do it. Here are a few:
Internally do all your work in Mecurial Queues and then qfinish the changesets only when done / perfect. Give them access to the repo but not the mq repo (they're optionally, separately versioned)
Use things that rewrite history like commit --ammend or histedit's collapse command to alter the repo after you like it (drawback, everyone on your team has to delete and reclone)
create a totally separate repo for them and when you're ready to give them a drop copy in a hg archive from your repo and commit
I don't think any of those are worth the hassle of hiding normal software development work, but there you go.
Using MQ is good way, using MQ with TortoiseHG is also easy way to rewriting history.
In your case you can create, have and maintain two related repository: "Dirty" and "Clean"
Clean can be created as clone of used in work Dirty (and doesn't cloned after it to developers)
In Clean you'll enable MQ extension and rewrite history in Mercurial's CLI (or with TortoiseHG)
Coming originally from SVN, I am still new to Mercurial.
I am interested in creating an experimental workflow to see if I can rewrite a troubled feature from scratch. If my attempt fails though, I wish to delete the experimental workflow - abandoning the work — with nobody else ever seeing it.
The problem is though I still need to push changes of this experimental workflow across laptops and PCs and keep working for a couple of weeks. But still keep the option open to delete that branch and fall back to the main branch, without having any trace of the experimental branch.
Is something like this possible in Mercurial and how could I achieve this?
FYI, I am using mercurialeclipse plugin on Aptana Studio 3.0. (so I
use a UI but commands should be fine too)
After changeset is pushed to the central server (assuming you have one) - there is no way to remove it from there.
So the possible (but terribly inconvenient) solution for you now could be to create a personal separated repository and synchronize your devices using it. And if you like the result - you push to the shared central repo then. Otherwise you just delete the temporary repository.
With a Distributed Version Control System like Mercurial you can sync between any clone of a repository, not just a "central" one that all users have agreed to use.
Therefore, you can:
Clone the repository to private a share that the systems "experimenting" can access.
Clone to a USB key and move that between systems.
Use hg serve to start a web server for a local repository on a system and clone and pull that history to other systems.
Use hg bundle/unbundle to package up new history and email it to another system.
To abandon work, just delete all these extra clones and clone from the common "central" repository again.
I'm in a small distributed team using Mercurial for a central repository. We each clone it via ssh onto our own linux boxes. Our intent is to review each others' work before pushing changes up to the central repository, to help keep central's tip clean. What is a good way to share code between developers on different linux boxes? I'm new to Mercurial. The options I can think of (through reading, not experience) are:
1: Author commits all local changes and updates working clone with central's tip. Author uses hg bundle, if there's a way to specify which local revs to include in the bundle. (an experiment showed me "bundle" only grabs uncommited changes, even if there are previous local commits that central doesn't know about) Author gets bundle file to reviewer. Reviewer creates a new clean clone from central's tip, and imports the bundle into that clone.
or,
2: After both author and reviewer fetch from central's tip, author uses patch and reviewer imports the patch.
or,
3: Author pushes to reviewer or reviewer pulls from author (but how, exactly? What I read is only about pushing and pulling to/from the original served repository, and/or on the same box instead of between different linux boxes.)
4: Forget reviewing the code prior to pushing to central; go ahead and push, using tags to identify what's been reviewed or not, and use Hudson (already working) to tag the latest safe build so team members can know which one to pull from.
If your team uses Mercurial and does code reviews, how do you do get the reviewer to see your changes?
Most of these are possible, some are more tedious than others.
You can use bundle by specifying the tip of the central repo as the --base:
hg bundle --base 4a3b2c1d review.bundle
Might as well just use bundle. That way, the changeset data is also included.
You can push (and pull) to (from) any repository that has a common ancestor(s). If you want to pull from one of your colleagues, they just need to run hg serve on their machine, and you will be able to pull.
This also works, but you will have to maintain multiple heads and be careful about merging. If you don't, it can become easy to base a stable change on top of an unreviewed changeset, which will make it hard to undo if you need to fix that unreviewed changeset later.
Of the options you presented, #1 and #3 are probably easiest, just depending on whether or not you can reach each other's boxes.
On a related note: This is the question that got my colleague and I started on developing Kiln, our (Fog Creek's) Mercurial hosting and code review tool. Our plan, and the initial prototype, would keep multiple repositories around, one "central" repository, and a bunch of "review" repositories. The review process would be started by cloning the central repo into a review repo on the server, and then running a full repo diff between the two, with a simple web interface for getting and viewing the diffs.
We've evolved that workflow quite a bit, but the general idea, having a branch repo to push unreviewed changes to and an interface to review them before you push them into the central repo, is still the same. I don't want to advertise here, but I do recommend giving it a try.
Half answer to this question is using ReviewBoard with Mercurial extention. It allows to push certain revisions for review by issuing the following command
hg postreview tip
I'll add a 5th option - do all development work on named branches, preferably one per task. Allow anything to be committed to a "development" named branch, whether it's in working state or not.
Push to the central repository, have reviewer pull the branch. Perform the review on the branch.
When the review has passed, merge the development work into the appropriate feature branch.
This workflow, which is (to me) surprisingly unpopular, has many advantages:
All work gets committed - you do not have to wait for a review to be done before committing.
You will not build off the wrong version. You only ever build from the feature branch.
In-progress work does not interfere with other developers.
From the development branch, you can either look at the latest changes (e.g. the changesets addressing review comments), compare with the branch point, or compare with the latest feature branch - all of which can give useful information.
We got all psyched about from from svn to hg and as the development workflow is more or less flushed out, here remains the most difficult part - staging and integration system.
Hopefully this question goes a bit further then your common 'how do I move from xxx to Mercurial'. Please forgive long and probably poorly written question :)
We are web shop that does a lot of projects(mainly PHP and Zend), so we have one huge svn repo, with like 100+ folders, each representing a project with it's own tags,branches and trunk of course. On our integration and testing server(where QA and clients look at work results and test stuff) everything is pretty much automated - Apache is set to pick up new projects automatically creating vhost for each project/trunk; mysql migration scripts right there in trunk too and developers can apply them through simple web-interface. Long story short our workflow is this now:
Checkout code, do work, commit
Run update on the server via web interface(this basically does svn up on server on a particular project and also run db-migration script if needed)
QA changes on the server
This approach is certainly suboptimal for large projects when we have 2+ developers working on the same code. Branching in svn was only causing more headaches, well, hence moving to Mercurial. And here is where the question lies - how does one organize efficient staging/integration/testing server for this type of work(where you have many projects, say single developer could be working on 3 different projects in 1 day).
We decided to have 'default' branch tracking production essentially and then make all changes in individual branches. In this case though how can we automate staging updates for each branch? If earlier for one project we almost always were working on trunk, so we needed one DB, one vhost, etc. now we potentially talking about N-databases per project, N-vhost configs and etc. Then what about CI stuff(such as running phpDocumentor and/or unit tests)? Should it only be done on the 'default'? On branches?
I wonder how other teams solve this issue, perhaps some best practices that we're not using or overlooking?
Additional notes:
Probably worth mentioning that we've picked Kiln as a repo hosting service(mostly since we're using FogBugz anyway)
This is by no means the complete answer you'll eventually pick, but here are some tools that will likely factor into it:
repositories without working directories -- if you clone -U or hg update null you get a repository with no working directory (only the .hg). They're better on the server because they take up less room and no one is tempted to edit there
changegroup hooks
For that last one the changegroup hook runs whenever one or more changesets arrive via push or pull and you can have it do some interesting things such as:
push the changesets on to another repo depending on what has arrived
update the receiving repo's working directory
For example one could automate something like this using only the tools described above:
developer pushes five changesets to central-repo/project1/main
last changeset is on branch 'my-experiment' so csets are automatually re-pushed to optionally created repo central-repo/project1/my-experiment
central-repo/project1/my-experiment automatically does hg update tip which is certain to be on the my-expiriment branch
central-repo/project1/my-experiment automatically runs tests in its working dir and if they pass does a 'make dist' that deploys, which might set up database and vhost too
The biggie, and chapter 10 in the mercurial book covers this, is to not have the user waiting on that process. You want the user to push to a repo that contains possibly-okay-code and the automated processed do the CI and deploy work, which if it passes ends up being a likely-okay repo.
In the largest mercurial setup in which I've worked (20 or so developers) we got to the point where our CI system (Hudson) was pulling from the maybe-ok repos for each periodically then building and testing, and handling each branch separately.
Bottom line: all the tools you need to setup whatever you'd like probably already exist, but gluing them together will be one-off sort of work.
What you need to remember is that DVCS (vs. CVCS) introduces another dimension to versioning:
You don't have to rely anymore only on branching (and get a staging workspace from the right branch)
You now have with DVCS the publication workflow (push/pull between repo)
Meaning your staging environment is now a repo (with the full history of the project), checked out at a certain branch:
Many developers can push many different branches to that staging repo: the reconciliation process can be done in isolation within that repo, in a "main" branch of your choice.
Or they can pull that staging branch in their repo and test things out before pushing back.
From Joel's tutorial on Mercurial HgInit
A developer don't necessary have to commit for other to see: the publication process in a DVCS allows for him/her to pull the staging branch first, reconcile any conflict locally, and then push to the staging repo.
I'm working on setting up a Hudson/Mercurial stack for development. One of the use cases I have is "As a developer, I want to update my local sandbox to a particular build number from Hudson, so I can [fix a bug, debug issues, create a branched version of code, etc.]."
So, if I see build #49 on Hudson, how do I update my local Mercurial repo to the same source code that was used to build #49?
Note: I have looked at Mercurial tags, however they don't seem quite appropriate. They require a commit, so it seems the commits will dirty up the history (each commit by a developer will show a subsequent commit from the tag operation). If this is the best there is, I guess I will have to live with it, but hoping for something better. Would probably still use tags for releases.
Ok, here's the solution I ended up with:
Using the Description Setter Plugin, I set both the success and failing build description to "Mercurial ${MERCURIAL_REVISION}". Turns out the current Mercurial SCM plugin sets this environment variable to the parent changeset id.
I can then look at a build on Hudson, and if so desired, grab the changeset id and do a "hg update " on my local repo to get that revision of code.
Note that in the Mercurial plugin issue tracker there is some talk of changing this to HG_REVISION instead and adding other environment variables, so this may break at some point in the future, but works for me for now.
You can use the keywords extension on the hudson system to update the nodeid into some aspect of the build, possibly including the artifact names. If the Hudson job output artifacts are like: myproject-2010-02-17-2dbf7575fa46.tar.gz you certainly know how to 'hg update' to that point in time.
The keywords extension and maybe a little ant-fu make that easy to do.