We are trying to implement differential metrics report in Gitlab https://docs.gitlab.com/ee/ci/testing/metrics_reports.html to display difference in metrics (typically: bundle size) introduced by the MR.
The mechanism is not very clear to us: we know hot to create the metrics.txt for the SOURCE branch, but we don’t understand how to compare it to the metrics.txt of the DESTINATION branch. We have googled the planet without finding much info. Anybody has already implemented this feature?
We figured out that the metrics.txt is generated as ARTIFACT during the pipeline execution, and remains there for comparisons against a MR. It's not necessary to commit the metrics.txt in the baseline. The stats.json is generated by webpack-analyze and can be accessed in ${projectPath}/jobs/${args[0]}/artifacts/PROJECT_NAME/packages/${packageName}/build/stats.json`, and from this stats.json we can extract the metrics into ./metrics.txt and store it as artifact.
Related
We are trying to migrate our old issue "tracking" system to GitLab.
For legacy reasons the issues have relatively large numbers 800 and above and they are not consecutive.
However for backreference it would be great if we could have one number for each issue and not an "old" and a "new" number, as in some contexts issues are referred to by number (e.g. external parties who in the future also will use GitLab)
I found this Set Minimum Issue Number in Gitlab where issues were created to "fill" the gaps. However this creates a lot of clutter (especially E-Mails Gitlab API - Create issue quietly?).
Any ideas how to solve this?
The ideal flow would be:
use gitlab-api to create issues we have and
add a parameter so set the number of the issue.
When using gitlab, the numbers are filled up by new issues over time,
or they count up from the highest issue number currently in the
project.
If I could actually set the issue number afterwards in the database (as was hinted in the linked question above), how will gitlab handle this? (I don't even know where to start looking in the gitlab code base, any hints on that might also answer this question).
Thanks in advance for any advice on how to tackle this.
I found a trick to do that.
There is exporting to .csv from the GitLab and .csv is an editable format. It can be edited in any excel-like program, or even in a notepad.
Make a first issue, fill it with dummy data (I suggest filling as that's a way to spot which field is responsible for what).
Then fill your data by any way suitable, preferably mass-exported from the previous issue tracker and import back to the GitLab.
If done correctly, this should be possible to be done partly automatically.
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 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.
I have an issue on gitlab, #1. This issue when it was created it contained two tasks.
Is there a way to mention/reference/close one of the two tasks in a git commit ?
Not yet, but at least you can define tasks in an issue now.
This comes with GitLab 15.3 (Aug. 2022)
Create tasks in issues
Tasks provide a robust way to refine an issue into smaller, discrete work units.
Previously in GitLab, you could break down an issue into smaller parts using markdown checklists within the description.
However, these checklist items could not be easily assigned, labeled, or managed anywhere outside of the description field.
You can now create tasks within issues from the Child Items widget.
Then, you can open the task directly within the issue to quickly update the title, set the weight, or add a description.
Tasks break down work within projects for GitLab Free and increase the planning hierarchy for our GitLab Premium customers to three levels (epic, issue, and task).
In our next iteration, you will be able to add labels, milestones, and iterations to each task.
Tasks represent our first step toward evolving issues, epics, incidents, requirements, and test cases to work items.
If you have feedback or suggestions about tasks, please comment on this issue.
See Documentation and Epic.
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.