We are setting the CI on our GitLab and we are able to show build status and code coverage on master using the following:
README.md in root directory of myproject:
[![build status](http://mygitlab/mygroup/myproject/badges/master/build.svg)](http://mygitlab/mygroup/myproject/commits/master)
[![coverage report](http://mygitlab/mygroup/myproject/badges/master/coverage.svg)](http://mygitlab/mygroup/myproject/commits/master)
Something we would like is show build status/code coverage of current branch when viewing the README.md in the branch. Right now, the links have master hardcoded so the branches show the status of the master.
Is there a way to use relative URL (or something else) so the build status / code coverage automatically adapt to the branch you're viewing? Looking at the documentation, it looks like it's impossible, because you have to specify the branch.
Starting in GitLab 9.3 (available only in Starter/Bronze and higher), code quality will be evaluated as part of the CI/CD pipeline and the results will display in the merge request.
You can see an example of how this looks in a merge request in the documentation at GitLab Code Quality.
This works 'automatically' via Auto DevOps or you can configure Code Quality manually by using the Code Quality examples
This doesn't address showing code quality and pipeline status for a given branch in the README. As mentioned, it does show the pipeline status and code quality in the MR itself. However, when viewing a particular branch, the commit at the top of the page does show the overall pipeline status. Click on that status to go to the pipeline for more detailed job information, including the Code Quality job itself.
It's not quite as handy as what you're looking for, but it is a workaround. Usually, concerns about quality and build status are most important on the proposed merge request itself, where fixes can be made prior to merging them into the master/target branch.
What I would really like to see is what the Code coverage was Before and After a merge request, while reviewing merge requests
Actually, this is easier with GitLab 13.4 (September 2020)
Show job data for Code Coverage value in MR
As a developer, you should be able to easily see code coverage after a pipeline finishes running, even in complex scenarios that make this more difficult, like when your pipeline has multiple jobs that are parsed to calculate the coverage value.
Until now, the Merge Request widget only showed the average of those values, which meant you had to navigate to the jobs page and then back to the Merge Request itself to get more granular details for the coverage value.
To save you time and eliminate those extra steps, you’re now presented with the average coverage value, how it has changed from the target and source branch, and a tooltip that shows the coverage for each job used to calculate the average.
See Documentation and Issue.
Is there a way to show build status/code coverage per branch
One new feature which does relate to this is with GitLab 13.6 (November 2020):
Pipeline status in branch and tag lists
If you use CI/CD pipelines with tags or branches and want to know the latest pipeline status, you previously had to navigate away from the branch list or tag list to get to the pipeline page. Now, pipeline status icons are displayed for each branch or tag in their respective list views so you can quickly get to this information for many tags or branches in less clicks.
Thanks to Lee Tickett for this contribution!
See Documentation and Issue.
Related
Say I have 10 commits in my merge request. I'd like to see all changes made between the first commit and the second to last commit. How can I see this in the GitLab UI?
You can view 'Changes' tab to view all changes in merge request
You can also click on individual commits to view what is changed in that particular commit
You can check diff between two arbitrary commits using https://gitlab.com/$USER/$REPO/compare?from=$SHA1&to=$SHA2
Reference:
https://stackoverflow.com/a/50070145/2073920
Use format
https://gitlab.com/$USER/$REPOSITORY/compare?from=commit_hashtag1&to=commit_hashtag2
For example, You use URL like this
https://gitlab.com/Donhu/java_examples/compare?from=7f844e6b&to=1ff5c89c
I'm new to GitLab ci and I was curious if something could be done inside the .gitlab-ci.yml. For our project we want two different things to happen dependent on two actions. For instance, when a new file is added to the master branch we want Job1 to run. However, when a file is updated in the master branch we would like Job2 to run instead.
Based on reading through Gitlab's documentation on ci/cd it looks like you could do this by using variables and rules.
So, would this be possible inside the yml file or would you have to go about it another way?
Thank you for your replies.
As you might have already noticed there is a rule named changes which you could try out. If that's not sufficient you still could execute something like git diff-tree inside a container and then decide what to do.
I doubt that you can do it directly with a conditional over a file because the commit push (which is the action that triggers the pipeline containing the job, ultimately) could contain several files.
Having said that, you have a bunch of predefined variables with information about the commit itself, so maybe you can agree with the team on a commit description template for when they add a file and another one for the case of the update. Then you can easily use rules to determine which job has to run. For this particular case, you will be using the CI_COMMIT_DESCRIPTION variable.
You can also base your condition on a tag, but I think that it will make the repository too dirty.
I know that it is easy to forget the rule, but still, it is an easy workaround.
I want to have an option on the cucumber report to mute/hide scenarios with a given tag from the results and numbers.
We have a bamboo build that runs our karate repository of features and scenarios. At the end it produces nice cucumber html reports. On the "overview-features.html" I would like to have an option added to the top right, which includes "Features", "Tags", "Steps" and "Failures", that says "Excluded Fails" or something like that. That when clicked provides the same exact information that the overview-features.html does, except that any scenario that's tagged with a special tag, for example #bug=abc-12345, is removed from the report and excluded from the numbers.
Why I need this. We have some existing scenarios that fail. They fail due to defects in our own software, that might not get fixed for 6 months to a year. We've tagged them with a specified tag, "#bug=abc-12345". I want them muted/excluded from the cucumber report that's produced at the end of the bamboo build for karate so I can quickly look at the number of passed features/scenarios and see if it's 100% or not. If it is, great that build is good. If not, I need to look into it further as we appear to have some regression. Without these scenarios that are expected to fail, and continue to fail until they're resolved, it is very tedious and time consuming to go through all the individual feature file reports and look at the failing scenarios and then look into why. I don't want them removed completely as when they start to pass I need to know so I can go back and remove the tag from the scenario.
Any ideas on how to accomplish this?
Karate 1.0 has overhauled the reporting system with the following key changes.
after the Runner completes you can massage the results and even re-try some tests
you can inject a custom HTML report renderer
This will require you to get into the details (some of this is not documented yet) and write some Java code. If that is not an option, you have to consider that what you are asking for is not supported by Karate.
If you are willing to go down that path, here are the links you need to get started.
a) Example of how to "post process" result-data before rendering a report: RetryTest.java and also see https://stackoverflow.com/a/67971681/143475
b) The code responsible for "pluggable" reports, where you can implement a new SuiteReports in theory. And in the Runner, there is a suiteReports() method you can call to provide your implementation.
Also note that there is an experimental "doc" keyword, by which you can inject custom HTML into a test-report: https://twitter.com/getkarate/status/1338892932691070976
Also see: https://twitter.com/KarateDSL/status/1427638609578967047
I am a git person. In git, after I finishing a little feature, I will submit the branch to review and start a new branch to work on new features.
For example, I had submitted a code recview for feature A, and it is still under review. At this time, I want to start working on feature B, assuming feature A's code will be merged in the near future. In Git, typically I just create a new branch to work on the new feature, if there is some problem with feature A I can easily switch back to branch A to fix it and merge the fixed version to my new feature branch.
How's it achieved in perforce? Should I copy the whole code somewhere as a way to manage branch myself?
You can do this in Perforce exactly the same way you'd do it in Git, if you like -- create your feature B branch and work on feature B there. If you need to make changes to your feature A branch, those can be merged back to your mainline and/or your feature B branch.
If you do your code reviews as shelves, you can have any number of them in development at a time; a shelved change is effectively "rebased" onto submitted changes when you sync+resolve.
FWIW, usually the way I've done reviews in Perforce is to make my changes on my own development branch, set up the merge to the mainline, and then shelve that for review. That way I can continue work on my development branch uninterrupted, I don't need to create a new branch, and if there's a fix needed to my merge-in-progress I can just amend the shelved change (either by submitting the fix to my branch and adding it to the merge, or making the edit as part of the merge operation); it also has the benefit of making conflict resolution (if any) part of the change under review.
GitLab jobs can produce artefacts. Artefacts are produced by specific runs (unique id job_id and are associated to a jobs name job_name (defined in the project's .gitlab-ci.yml) and a ref (e.g. branch). A (ref, job_name) can have multiple job_id, but typically the relevant one is the most recent one.
For an artefact htmlcov/index.html produced by the job %{job_id}, its respective page is given by the URL
https://%{namespace}.gitlab.io/-/%{project_name}/-/jobs/%{job_id}/artifacts/htmlcov/index.html
As per link above, I know that I can browse the artefact using the URL
https://gitlab.com/%{namespace}/%{project_name}/-/jobs/artifacts/%{ref}/browse?job=%{job_name}
Question
Given a %{ref} and a %{job_name}, What is the URL of the artefact produced by the latest %{job_id}?
I am unable to construct the URL for the pages (typically starting with https://%{namespace}.gitlab.io. I tried different variations of
https://%{namespace}.gitlab.io/-/%{project_name}/-/jobs/%{job_id}/artifacts/htmlcov/index.html
such as
https://%{namespace}.gitlab.io/-/%{project_name}/-/jobs/%{ref}/artifacts/htmlcov/index.html?job=%{job_name}
but all lead to 404. Any suggestions?
This seems to be an existing but undocumented feature. Use
https://gitlab.com/%{namespace}/%{project_name}/-/jobs/artifacts/%{ref}/file/%{path}?job=%{job_name}
for example,
https://gitlab.com/jorgecarleitao/schemaflow/-/jobs/artifacts/master/file/htmlcov/index.html?job=coverage
There is now an Merge Request to add this to gitlab's documentation.