What does the "Next" flag indicate on GitLab top bar? - gitlab

This morning when I logged into GitLab I noticed this "Next" flag on the top bar:
It appears whether I am logged in or not. What does "Next" indicate?
A Google search turns up nothing. It doesn't appear in any GitLab screen shots I am able to find either.

This is the canary version of Gitlab you are being served, you can find out more here: https://about.gitlab.com/handbook/engineering/#canary-testing
You can swap the version of Gitlab you see here: https://next.gitlab.com/?nav_source=navbar
The reasoning behind providing the Canary versions to users either at random or by those who have opt-ed in:
GitLab makes use of a 'Canary' stage. Production Canary is a series of
servers running GitLab code in production environment. The Canary
stage contains code functional elements like web, container registry
and git servers while sharing data elements such as sidekiq, database,
and file storage with production. This allows UX code and most
application logic code to be consumed by smaller subset of users under
real world scenarios before being made available to all users on
GitLab.com.

Related

Cloudflare Pages uses different sphinx version depending on commits and one is failing

I have a Cloudflare page that uses python-sphinxto build docs. For some of my commits, it downloads a different version of sphinx than others and fails to build docs correctly.
What I tried:
Adding a dummy commit on top of a failing build seems to fix an issue and force Cloudflare builder to download the correct sphinx version
re-running deployments doesn't fix the issue
creating a new branch with the same head(failing commit) and running another deployment doesn't fix the issue
changing between preview/production deployments has no impact on this issue
Here is a dummy commit I added to make the docs build correctly
Commit one result vs. Commit two result
The diff in deployment logs old commits, the left is Commit 1(not working), and the right, Commit two, correctly builds all three tasks and the releases.
https://www.diffchecker.com/ZpV8vE9D
I have tried making different branches and re-run deployments to check whether the sphinx version will change, but it seems like it's bounded the the "old commit". This is also an issue for other Cloudflare Pages, and using preview/production deployments has no impact on this problem.
The issue in this case was actually not with sphinx version but with the fact that I was using:
git fetch --all
Which does not guarantee pulling the tags with it.
The --all pull from all remotes instead of "everything" as I thought.
Using git fetch --tags instead fixed the issue
Indeed it seems to be a bug, in this case I recommend you to consult directly with CloudFlare support, sometimes they are errors that remain internally in your account and you unbug it, CloudFlare Pages for the moment continues to improve its system, there are details to be corrected.

Is it possible to set the expiration of artifact to 'next-successful-build' in gitlab?

In the documentation, it seems that we can set the expire-in to several days or weeks. But I cannot decide an accurate fixed date. Is it possible to always keep the 'lastest' artifact, and remove the old one when a new one is successfully built?
Okey. I found a solution here :
https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#keep-artifacts-from-most-recent-successful-jobs
With this help, it can be easily reached.
The question should be closed.
Here's the instruction given by gitlab official.
Keeping the latest artifacts can use a large amount of storage space in projects with a lot of jobs or large artifacts. If the latest artifacts are not needed in a project, you can disable this behavior to save space:
On the top bar, select Menu > Projects and find your project.
On the left sidebar, select Settings > CI/CD.
Expand Artifacts.
Clear the Keep artifacts from most recent successful jobs checkbox.
You can disable this behavior for all projects on a self-managed instance in the instance’s CI/CD settings.

Host multiple test reports with gitlab pages

We have a test suite in our gitlab pipeline which produces Allure test reports. To make these results available after the test, we currently publish the results to artifacts and have an allure serve running which makes them available over a subdomain, based on the branch name.
We would like to host the test results with gitlab pages for each branch. However we can only ever host one version of a page through gitlab pages at one time. This is a problem since we want to host the test results for each branch, not only for the last executed branch. It seems like this is currently not possible without hacks.
I also found this 3 year old gitlab issue about the topic which indicates this is coming in some version of gitlab in the future.
Is there a better way to do this? Or is our best bet currently to wait until this becomes available in gitlab?
If you want to show a test report summary for each pipeline build, you can use GitLab's "Unit test reports" feature. It is slightly different to GitLab Pages, but it's easier to use, because you don't have to configure and host web pages yourself.
You only need to specify the paths to the XML files of the test results, something like this:
java:
stage: test
script:
- gradle test
artifacts:
when: always
reports:
junit: build/test-results/test/**/TEST-*.xml
It will show the summary on GitLab's web page of the pipeline build results, like this:
Source and guidance:
https://docs.gitlab.com/ee/ci/testing/unit_test_reports.html
https://docs.gitlab.com/ee/ci/testing/unit_test_report_examples.html
https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#browsing-artifacts
and one HTML file that you can view directly online when GitLab Pages is enabled > (opens in a new tab). Select artifacts in internal and private projects can only > be previewed when GitLab Pages access control is enabled.
This sound to me like you just need GitLab pages enabled and then can browser HTML files from the artifacts repository.
(correct me if a m wrong)
From https://docs.gitlab.com/ee/user/project/pages/pages_access_control.html:
"You can enable Pages access control on your project if your administrator has enabled the access control feature on your GitLab instance. When enabled, only members of your project (at least Guest) can access your website"

Gitlab change default branch for every project

I am currently using GitLab Community Edition 9.0.0 and want to change default branch to "develop" for every project.
I know it can be done by project settings page but since we have almost 200 projects, is there easy way to do it?
You could use the Gitlab API to:
Get a list of all the projects (see here)
Loop on that list and edit every project to set the default_branch parameter (see here)
Here's more documentation on how to use the API.
You fist need to get a user's private token. Go to http://<gitlab_domain>/profile/account to get/generate one for your currently logged in user. You may want to do that as the gitlab administrator in order to have access to and be able to modify all those projects.
Then you need to generate the proper requests (see links above and this).

Gitlab markdown links to artifacts

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

Resources