Is it possible in Gitlab to have source controlled markdown that contains a link to an artifact?
My runner generates metrics that are saved to a file. This output, of course, does not belong in version control. If it was in version control, I could just link to it, no problem. Instead, I mark the output as an artifact so that it is saved after the build is complete.
Currently, our devs can click the [passed] icon for the build that generates the metrics, then click 'Build Artifacts'|'Browse'|dir1|... down to the generated output metric. This is complicated, and you have to know exactly where to look.
It would be way more convenient to have a link to the artifact in the README.md.
These docs say that I can choose to store my artifacts in a different location, but that seems like a heavy solution, and it does not generalize to artifacts from different projects.
These docs say that I can embed build numbers in the artifact filename, but that's not really what I'm after. I just want the artifacts from the most recent build.
What I want is a persistent URL for the artifact, but I am unable to find anything of this nature.
Update February 2018:
Since Gitlab 8.12, the link is https://gitlabInstance/myNamespace/repository/master/archive.zip. (e.g: https://gitlab.com/rpadovani/my-gitlab-ci/repository/master/archive.zip).
There are also other formats.
You can see all the formats clicking on the little cloud in the top right of the homepage of your project.
ORIGINAL ANSWER
They are working on it right now.
Since GitLab 8.10, there is an API to do that:
curl -H "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" "https://gitlab.example.com/api/v3/projects/1/builds/artifacts/master/download?job=test"
Unfortunately you still cannot use the web interface, but there is already a MR to implement it (and a related bug with discussion).
After that MR you can link the build in your README
Related
Problem Summary
I am creating my first GitLab pipeline and setting it up to do a release. I would like to add a change log to the published release information. (found in Deployments -> Releases in the GitLab UI).
I would like to, from the pipeline, query the project for something like "closed issues since the date of the last release" and add those tickets to the published release.
Planned Approach
I am successfully using the "release-cli" tool from GitLab to create the release. I followed the example: "Create release metadata in custom script" on this page.
I found the description tag in the release element can be given a .md file, which seemed perfect for posting my change log. I have made a test .md file and added it as the release description and it looks great. It shows up right under "Evidence Collection" and so I planned to do "Change Log" as the header in my .md file. In the above example, GitLab is clearly using an .md file in their description element for extra information such as this.
Where I'm Stuck
I just can't figure out how to query the gitlab project from the pipeline (for issues or whatever).
I have been looking at GitLab's cli project and see likely has all the tools I need. I can not find any examples of using it in a pipeline. I cannot find for sure that its in a docker image that I can use similar to the release-cli tool.
I am stuck. The lack of information makes me wonder if I'm going down a dead end path. Is there anybody that has done something similar that can give me a basic example? Or an alternative?
I have accidentally deleted a Wiki-page from our repository in Azure DevOps.
(How) can I recover it?
That is not an option for us, since we will loose many changes that
were made after the last version no. up until the date I accidentally
deleted the wiki page.
You can choose Clone wiki to download the wiki repo to local machine.
Then use git commands(git revert or what) locally to get the deleted page, once you find the deleted page, publish it and add it back to Wiki page as a new commit.
I was just able to do this without too much fanfare. The resource that was helpful was this VS community topic. There is an answer that provides a solution that doesn't require you to clone the repo.
The key insight is that you can navigate to the Azure DevOps repo UI for the Git repo that's backing the wiki. The solution author says that the shape of the URL is something like https://dev.azure.com/<organization-name>/<project-name>/_git/<wiki-name>.wiki. This didn't quite work for me because we have a different URL scheme in our organization, but I was able to figure it out after a little trial and error. I later saw that you can get the URL by using the Clone Repo UI in the wiki - it gives you the URL, so you can just copy it and navigate to it.
Anyway, the steps were:
Figure out the URL of the git repo that backs the wiki
Navigate to the revision history for the entire wiki
the current UI shows you the Contents tab by default - switch to History
Scroll until you find the commits that deleted the pages you want to restore
it's one of those list views that populate themselves as you scroll, so you won't be able to use the browser page search efficiently, unfortunately
Revert the commits
In my case, this required clicking on them and creating pull requests to revert, but I was able to merge them myself without involving code reviewers. YMMV
All in all, not a wholly terrible experience, but completely undiscoverable.
Assuming you're managing a provisioned wiki (vs using published code as a wiki):
Look in the top-right corner for the vertical 3-dot menu, where there's an option to view revisions:
Choose the revision you want to revert to (e.g. the one prior to deleting the needed wiki page), from the list (click on its version hash):
From the revision details, select "Revert":
At this point, your wiki should be at its prior state, and your wiki page should once again be available.
Note: If you're using published code as a wiki, you would recover/revert your changes as you would with any other code commit.
More details may be found here.
I couldn't find a way to do this through the Azure DevOps web interface but you can restore the page by reverting the commit that deleted it if you clone the wiki locally.
Clone the wiki to your computer - find the clone wiki option in the menu at the top of the left bar which shows the wiki contents, copy the URL and use to clone locally using your usual git client.
Find the commit that deleted the page, the commit message will start with "Deleted page" then the name of the page you deleted.
Restore the page and commit the change. There are various ways to do this - I reverted the commit, you could checkout the commit and copy the page out to make a new commit. You may get a merge conflict on '.order', I'm not sure what the best thing to do is but I kept the current version and haven't had any problems.
Push the changes to Azure DevOps, refresh and you'll see the page has been restored.
This works even for Project Wikis. I wonder if Azure DevOps has added the functionality that enabled this since some of the other answers have been written.
As the standard pipeline badge from GitLab looks like this
you can tell pretty well that those are not really distinguishable.
Is there a way to change the pipeline text manually or programmatically to something else for each badge?
Btw, the badges were added with those links
https://gitlab.com/my-group/my-repository/badges/master/pipeline.svg
https://gitlab.com/my-group/my-repository/badges/dev/pipeline.svg
Additional facts:
The pipeline runs locally on my computer
My repo is private
I know it is a bit of an old post, but I was looking for the same and found that it is available now since GitLab 13.1.
The text for a badge can be customized to differentiate between multiple coverage jobs that run in the same pipeline. Customize the badge text and width by adding the key_text=custom_text and key_width=custom_key_width parameters to the URL:
https://gitlab.com/gitlab-org/gitlab/badges/main/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130
The example is for the Coverage badge but this also works for Pipelines, so in your case:
https://gitlab.com/my-group/my-repository/badges/master/pipeline.svg?key_text=master&key_width=50
https://gitlab.com/my-group/my-repository/badges/dev/pipeline.svg?key_text=dev&key_width=50
(Found this via https://microfluidics.utoronto.ca/gitlab/help/ci/pipelines/settings.md#custom-badge-text)
There are multiple ways how you can achieve custom pipeline badges in GitLab.
One way could be to use Shields.io which provide a way to generate dynamic badges for your Gitlab repository via a jsonfile.But if your repository is private (only accessible from internal network) then you will get an inaccessible message in your badges.
Otherwise, if your build uses python Docker images or any other python installation with dependencies, you can simply install the anybadge package and generate svg badges to be used in the project from the artifacts directly.
It would be good in future that GitLab offers us more cleaner way to customize the badges, but for now I think those are the workaround solutions.
I’m trying to set up GitLab CI/CD for an old client-side project that makes use of Grunt (https://github.com/yeoman/generator-angular).
Up to now the deployment worked like this:
run ’$ grunt build’ locally which built the project and created files in a ‘dist’ folder in the root of the project
commit changes
changes pulled onto production server
After creating the .gitlab-ci.yml and making a commit, the GitLab CI/CD job passes but the files in the ‘dist’ folder in the repository are not updated. If I define an artifact, I will get the changed files in the download. However I would prefer the files in ‘dist’ folder in the to be updated so we can carry on with the same workflow which suits us. Is this achievable?
I don't think commiting into your repo inside a pipeline is a good idea. Version control wouldn't be as clear, some people have automatic pipeline trigger when their repo is pushed, that'd trigger a loop of pipelines.
Instead, you might reorganize your environment to use Docker, there are numerous reasons for using Docker in a professional and development environments. To name just a few: that'd enable you to save the freshly built project into a registry and reuse it whenever needed right with the version you require and with the desired /dist inside. So that you can easily run it in multiple places, scale it, manage it etc.
If you changed to Docker you wouldn't actually have to do a thing in order to have the dist persistent, just push the image to the registry after the build is done.
But to actually answer your question:
There is a feature request hanging for a very long time for the same problem you asked about: here. Currently there is no safe and professional way to do it as GitLab members state. Although you can push back changes as one of the GitLab members suggested (Kamil Trzciński):
git push http://gitlab.com/group/project.git HEAD:my-branch
Just put it in your script section inside gitlab-ci file.
There are more hack'y methods presented there, but be sure to acknowledge risks that come with them (pipelines are more error prone and if configured in a wrong way, they might for example publish some confidential information and trigger an infinite pipelines loop to name a few).
I hope you found this useful.
I understand that gitlab has support to Jenkins CI, but what I need is a lot less than that.
I have a Rails application and get the coverage from the tests using simplecov. It generates HTML output in a directory by running a rake task. I would like to see the current coverage through gitlab. Is there a simple way to integrate this report with gitlab?
I fear there is still no easy way to integrate code coverage reports but Gitlab now supports (since Version 8.0 integrated) build jobs for your code. Unfortunately you have to implement your solution by writing a custom .gitlab-ci.yml to run your coverage tests. For viewing the reports, you can specify the generated "artifacts" or publish them on gitlab pages.
For more information, see here: https://about.gitlab.com/gitlab-ci/
Additionally you can parse a text output to display a short code coverage report:
(Enable builds and output test coverage)
Go to "Project Settings" -> Builds
Add to "Test coverage parsing" a regular expression (examples below, simplecov included)
See Publish Code Coverage Report with GitLab Pages
The short answer: Unfortunately there is no easy way to do this.
The longer answer:
GitLab not yet has a Jenkins support.
What you basically need is a service like GitLab CI or Jenkins CI, which starts simplecov and posts the output back to GitLab. Unfortunately GitLab does not offer such a functionality yet.
But I know other organizations which do have a Jenkins service for GitLab which automatically comment git pushes with the Jenkins result.
You now (June 2020, GitLab 13.1) have code coverage history, in addition of Test coverage parsing.
Graph code coverage changes over time for a project
All too often, a project has a code coverage target but development teams might not have much visibility into which direction that target value is trending over time.
There needs to be an easier way to track changes in code coverage over time without that extra hassle.
The Code Coverage graph now provides better visibility into how code coverage is trending over time.
It displays a simple graph of the coverage value(s) calculated in pipelines.
See Documentation and Issue
With GitLab 13.6 (November 2020), you also have (not for free though)
Display code coverage data for selected projects
In 13.4, we released the first iteration of Code Coverage data for Groups that enables you to compare the coverage of multiple projects and download the data in a single file from a single screen. However, to analyze the data, you had to open the file to check it manually, and probably imported it into a spreadsheet for further analysis.
In GitLab 13.6, you can now select specific projects in a group to see their latest coverage values directly in GitLab itself without needing to download a file or waste development time accessing code coverage data. We welcome feedback on the functionality and possible iterations for this feature in our feedback issue.
See Documentation and Issue.