In Azure DevOps, is there an easy way to find the total number of commits by developer within a specific time period? Possibly with the number of lines added/removed as well? Based on 1 repo or multiple.
Similar to this image from GitHub...
I think this is a general git question.
What we did in our peoject is similar to Git number of commits per author on all branches
You would go for something like:
git shortlog -s -n --all --no-merges --since="22 Aug 2019" --before="01 Sept 2019"
This would result in:
you could also add the author by adding --author=name like:
I would suggest to read the docs for options.
You could check out the marketplace. A possible extension would be Contributions Graph, which also allows you to select one or more repositories.
If you use VisualStudio, a quick way to achieve the number of commits is to copy and paste the changeset history into excel and filter by user. It's not something I'd want to use regularly but it works.
It's worth mentioning though, that lines of code committed can be misleading and therefore unfair to the coders. Good code can be a lot shorter than bad code. And lots of code might just contain external libraries etc.
Related
I have a project, based on buildroot, which is composed of two repos:
Buildroot root, let's say project A
Our packages, project B
We host a Gitlab server, and I'd like to set up a CI/CD job for the compilation.
The process I want to set up is as follow:
If a merge request (MR) appears on A/B -> trigger a pipeline.
If two MRs appears on both repos, referring the same issue, in a 15 minutes interval (this timer is to give some time to the developer to create all his MRs for his issue) -> trigger a single pipeline visible for both of the MRs.
The last point is where I struggle. Basically, what I want is to have one unique pipeline for one issue, so that if both repos have a MR for this particular issue, my pipeline would checkout on the correct branch for A and B and then launch the compilation for it.
I know I can trigger a pipeline on repo A from B, but I can't figure out how to ensure a unique pipeline will be launched if two MRs are created. Because right now, from what l can see, each MR would create it's pipeline and I'll end up with two compilations...
I've thought about using buildbot with Gitlab, but I'd prefer to stay on Gitlab only, because it's easier to maintain, than having many different tool for this.
Does anyone have ever faced this kind of problem on Gitlab and/or have a clue on how to deal with it ?
Thanks in advance!
Edit
I've come across this page which appears to be the exact solution to my problem, and unfortunately that seems not to be on the roadmap.
I'll dig into the proposition of having a meta project above A and B, because it would allow me to keep everything with Gitlab-CI, even if it means creating this project and dealing with a special process...
Answering my own question.
I've been trying to build up a setup with buildbot for several days, but as I said I really don't wanna add another tool to manage (my team isn't ready for this, and buildbot does too many things that we don't need for now).
I've come into this comment which made me chose the following approach.
Gitlab.example.com
A B *NEW Project 'C' only for CI/CD*
------\/------ ----------------\/--------------
- Trigger C with Key for the issue X, - Fetch/clone A and B for issue X
unless one already exists for issue X - Prepare the sources
- Wait for C to finish - Compile
- Report C's status (with URL to the
corresponding Pipeline)
This setup is the best I can get for a Gitlab-only solution.
If someone's interested in the code I used, tell me and I'll post sample.
In Gitlab CE, one can filter Merge Requests on Author, Assignee, Milestones and Labels. We cannot find a way to filter the search by Target Branch. Are we missing how this is done, or is that feature not available?
In Github, this is done by entering base:x where x is the branch to filter by under Pull Requests.
Unfortunately, it is not yet possible to filter Merge Requests by the destination branch, although it is an open feature proposal in issue 22135. I apologize that this may not be the answer you were hoping for.
Please feel free to mark your support for the proposal, discuss any ideas, or even submit a merge request if you’d like to do so. You can do any of these from the issue page and I encourage you to lend your voice to the development of this feature.
Yes, here's how!
https://gitlab.com/gitlab-org/cli/-/blob/main/docs/source/mr/list.md
glab mr list --target-branch=trunk
The ability to filter merge requests by target branch is now implemented directly in GitLab via https://gitlab.com/gitlab-org/gitlab-foss/-/issues/33831 since about 2020.
I'm new at using Perforce and I am faced with a dilemma. I am working on two different projects and I'm trying to figure out if there is any way to separate the revision numbers between them.
The setup is something like this:
Depot 1 stores Project 1 and I use Workspace 1 to work on it
Depot 2 stores Project 2 and I use Workspace 2 to work on it
However, they don't have separate changelist numbers (when looking under history) and this is a little confusing (working with different people on them as well). The same revision number goes up whenever I submit from either of the projects.
Is there any way to have separate the revision counters for the two projects?
Edit: On closer examination, the revisions are separate for the actual files, is this an issue with how Perforce shows the changelist(?) number when switching between depots?
The files in the different projects each have their own history, and each file has its own revision numbers, while there are also repository-wide ways to refer to instants of time in the overall repository, such as by date and by change number.
Try looking at 'p4 help files', 'p4 help revisions' and 'p4 help filelog' to get an introduction to the various techniques.
Also install P4V and get comfortable with using tools like Time-Lapse View, the Revision Graph, and Folder Diff, as these are very important when comparing different work among different projects in your repository.
Lastly, labels can help you associate logical mnemonic names with particular sets of revisions, so look into 'p4 help label' and 'p4 help tag'.
In specific, I would like to maintain a baseline set of requirement work items but also develop a second subset of slightly modified requirements for a related product without 'copying' them to a second project.
In Polarion 2012 you can actually branch whole document with those workitems. I guess that's feature exactly for you.
See what is new here http://blog.polarion.com/archives/1922
We are investigating a workflow in Perforce where we create a new temporary branch for every feature project. When projects are stable, they're integrated back into our main branch. Down the line, we would like to remove old project branches from the repository. However I believe this will also delete all revision history for the files modified in the branch. Is it possible to integrate the revision history from the project branches into the main branch?
One solution that I've considered is to manually integrate each individual checkin when merging code back into the main branch. This does not seem like the right approach.
The revision histories as stored against the branch they are applied to, so it is not possible to merge from one to the other. Your idea about integrating each changelist from the project branch will work, but is also a pain as you have pointed out.
I've made extensive use of branching over the years and I can't remember a case where we wished we'd had the branch revision history in the main line or even looked at the branch revision history after the branch was merged back into the main line.
You'll have the revision histories available (though not directly) for a while after a merge and (ideally) anything you check in to the main development branch should pass all the unit tests so the chances of it breaking should be minimised.
First of all, why do you want to remove the branches from the repository? Are you noticing having multiple branches to affecting performance (or expecting it to)? For each 'temporary' branch are you taking an entire copy of the main line? Also why do you consider these branches 'temporary', I would argue if they are for a feature then they are not and should be preserved.
A few articles to read:
- P4 KB Sparse Branching
- P4 Blog: Perforce Anti-Patterns Over-Branching
I believe, without knowing more information, that you could: use sparse branching, make these 'temporary' branches permanent, and if you really have a need for a temporary branch create a private working branch for each of your developers.