GitLab

GitLab 8.14.2 released

2016-12-01T00:00:00+00:00

Today we are releasing version 8.14.2 for GitLab Community Edition (CE) and Enterprise Edition (EE).

This version resolves a number of regressions and bugs in the recent 8.14 release</a>.

CE/EE: Rephrase some system notes to be compatible with new system note style (!7692</a>)</li>
CE/EE: Create tag after running pre-hooks and pass updated SHA to post-hooks (!7700</a>)</li>
CE/EE: Fixed commit time not rendering after initial page load (!7704</a>)</li>
CE/EE: Prevent error when submitting a merge request and pipeline is not defined (!7707</a>)</li>
CE/EE: Fix: Timeout creating and viewing merge request for binary file (!7713</a>)</li>
CE/EE: New system note design for commit discussion (!7721</a>)</li>
CE/EE: Refresh project authorizations using a Redis lease (!7733</a>)</li>
CE/EE: Fixed issue boards issue sorting when dragging issue into list (!7734</a>)</li>
CE/EE: Fix for builds with no start date throwing an error in cycle analytics events (!7738</a>)</li>
CE/EE: Clean up JiraService (!7756</a>)</li>
CE/EE: Update GitLab Workhorse to v1.0.1 (!7759</a>)</li>
CE/EE: Fix pipelines info being hidden in merge request widget (!7808</a>)</li>
CE/EE: Update Sidekiq-cron to fix compatibility issues with Sidekiq 4.2.1 (!7815</a>)</li>
CE/EE: Fix a transient spec failure (!7825</a>)</li>
CE/EE: Fixes access to the wiki code with git when repository feature disabled (!7832</a>)</li>
CE/EE: Revert bump in rufus-scheduler (!7844</a>)</li>
CE/EE: Make deleting with optimistic locking respect NULL (!7867</a>)</li>
CE/EE: Remove caching of events data (!6578</a>)</li>
CE/EE: Fix broken external links in help/index.html (!7582</a>)</li>
CE/EE: Evalute time_ago method instead of printing it (!7634</a>)</li>
CE/EE: Resolves updated and resolved status is not showing (!7655</a>)</li>
CE/EE: Fixed resolved discussion timeago not rendering (!7656</a>)</li>
CE/EE: Pick valid event objects for the events list (!7689</a>) </li>
EE: Port of rephrase-system-notes to EE (!913</a>)</li>
EE: Get rid of user activites table and replace it with redis (!915</a>)</li>
EE: Geo: Display Custom Avatars in secondary nodes (!904</a>) </li>
Omnibus GitLab: Revert default IPv6 configuration for NGINX (!1133</a>)</li> </ul>
Upgrade barometer</h2>
This version has no migrations and should not require any downtime.
Please be aware that by default the Omnibus packages will stop, run migrations, and start again, no matter how “big” or “small” the upgrade is. This behavior can be changed by adding a /etc/gitlab/skip-auto-migrations</code> file</a>.
Updating</h2>To update, check out our update page</a>. Enterprise Edition</h2> Interested in GitLab Enterprise Edition? Check out the features exclusive to EE</a>. Access to GitLab Enterprise Edition is included with a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.

How to Keep your Fork Up-To-Date with its Origin 2016-12-01T00:00:00+00:00 Have you ever wondered how to keep a fork automatically up-to-date with its origin (upstream)? In this post we'll show you how to do that on GitLab! Fork</h2> As you most likely know, a fork is a copy of a Git repository "connected" with the project you forked from (upstream). When you collaborate on code, it's pretty common forking a project, cloning to your local machine, making the changes you're up to, pushing to your fork, and submitting a merge request (MR) to merge your code into the original project. You fork a repository whenever you want to contribute to a project which you don't have access to, as it's not your own or your team's. This is how open source projects hosted by GitLab get so much collaboration from the community. When you are a member of a project (or a group), it's easier using the GitLab Flow</a>, or branching strategy, since anyone in your team can pull your branch and preview your changes locally. By the way, with our brand-new solution for this, called Review Apps</a>, you can preview your apps in a per-branch basis, for each MR submitted to GitLab, directly from a link generated by GitLab. Review Apps came to bring the GitLab Workflow</a> up to the next level! 🙌 The Problem</h2> When you fork a project and clone it to your local computer, you'll eventually need to update it with the master</code> branch of the upstream project (or whatever the default branch is set to). That way you will be able to checkout an up-to-date branch to work from. If you do not do that, you are very likely to stumble upon merge conflicts in the end, since the copy of the code you're working could be out-of-date. To prevent this, first you'd need to pull the upstream, push to the remote, checkout a new branch from the master</code> branch up-to-date, then finally start working on your changes. This takes time, and if you forget to do it, can cause a lot of pain. This process takes some time to complete, and turns out to be annoying if you need to do this multiple times a day. That's why we could use a better solution. The Solution</h2> GitLab can do that for you with no pain! Yay! What you need to do is very simple: enable GitLab Repository Mirroring</a>! First. Mirror your fork: Under your forked project's Settings, navigate to Mirror Repository: Second. Add the upstream's path to the field Git repository URL, then enable automatic mirroring: Third. Setup the mirror user: it's the user whose new commits to the upstream project will be attributed to in your fork. Done! Once an hour, GitLab will pull the upstream for you, and keep your fork up-to-date! By doing so, you only need to proceed as you usually do for your own projects (pull, checkout a new branch, and push your commits). All the rest GitLab does for you! Simple, isn't it? Repository Mirroring is available for free at GitLab.com and to all GitLab Enterprise Edition users. The Secret</h2> In order to pull without authentication from an upstream repository you are contributing to, the project should be public in the first place. Also, the Repository's Feature Visibility settings of the upstream project needs to be set to Everyone with access: You can find them in your project's Settings () > Edit Project. Note that you can mirror private projects as well, but you'd need to be a member of the project or the group it belongs. What is Your Solution?</h2> We would love to know how you do that! Do you have a different solution? You can certainly help others. Please share them in the comments, so everyone from the community can decide which solution is the best for them. Thank you! Conclusion</h2> Hopefully, we provided you with an easy solution for keeping your fork up-to-date. Remember, you can even mirror repositories hosted in other Git platforms! Cool! I'm looking forward to hearing from you: feedback, questions, and suggestions are very welcome! Leave your comment below, and/or tweet at us @GitLab</a>! We our community! How to explain GitLab to anyone 2016-11-30T00:00:00+00:00 How do you explain what GitLab is and how it works to a non-technical person? This is a challenge I’m facing right now, as I try to describe the company I just joined to my family and friends. Initial conversations were not very successful: Me: “It’s an open source workflow solution…” Them: “What’s a workflow?” Me: Them: Me: I’ve been getting closer (“We help people who write code to collaborate on projects”), but it’s still hard to drive the idea home in a way that really speaks to people – especially if they have only a vague idea of what coding is. In a team meeting we tried to come up with some real-world examples of how GitLab works, from using files on a computer, to DropBox, to Google Docs. But what if you’re talking to someone who’s not that comfortable with computers? Let’s bring it back to something relatable, paper!</h2> Say I’m a newspaper journalist collaborating with my team on a big story about a concert. We’ve been given a brief, but we each have different aspects of the story to cover: someone will interview the performers, someone else will provide some background about the venue. If we all worked on that original brief, we might end up writing over each other’s contributions and it would be hard to see what each person is working on. We have a meeting to divide up the work and establish what each team member’s task is and how we will approach it. To make things more efficient, we make photocopies of the brief so that each team member has their own copy that they can start adding to. We all have other articles we’re working on at the same time, so we spend some time prioritising tasks. I write a draft, and when I’m happy with my contribution, it needs to be fact checked and edited for spelling and grammar. Once a sub-editor gives it the go-ahead, I approach my editor to add my piece (currently on the photocopied brief) to the main story. My editor reviews my work, approves it for the story and includes it in the original. When this is done we create a mock-up of the newspaper page with the article so we can see how it will look. My colleagues go through the same process until all of their work is visible too – this happens every time a change is made, no matter how small, so we know that each new part of the story has been reviewed and checked for errors. When the deadline comes, we send the newspaper to the printers and then it gets distributed. We might get some responses to our story from readers who write in: someone might suggest some information that would have been useful to include in the article, so we update the online version of the article on our website and the new addition is visible right away. Other reader feedback might be useful for improving what we write about next time. This is how GitLab works!</h2> The process I described above is a workflow in which everyone collaborates to bring an idea to production</a>, and it’s a process that works just as well for developers making software as it does for my imaginary newspaper team. In GitLab, we start with an Idea (the main article that everyone will work on), then break it up into Issues (each team member’s tasks). To help us plan, we have an Issue Board to organize Issues into order of priority, just as the journalists had to work out how they were going to approach their tasks in amongst the other articles they are working on. To make sure we don’t overwrite each other’s work, we make our own ‘photocopies’ of the original idea: we call these Branches. Then, we code! This is like that first draft of my contribution to the story. When the code is ready, we Commit it, like a final draft. The sub-editor checking the work before updating the article is part of what we call Continuous Integration – a system by which the project is updated throughout the day, and those updates are automatically, continually checked for any problems. When I ask the editor to approve my contribution, we do this in the form of a Merge Request, and when that’s been approved, we can preview the changes in Staging, just like the newspaper team did with the mock-up of the page. If everything looks good, it goes into Production, the equivalent of going off to the printers. The last stage of the cycle is feedback: our ‘reader letters’ might be comments from colleagues or users, or data from analytics, and we use it to make sure we’re always improving. If there’s something we can change immediately, Continuous Deployment ensures the project is always up to date (like the newspaper’s website can show a change or addition to an article right away), and other feedback is used to do better next time. Image: "The Deptford Project — Newspaper</a>" by Eivind Z. Molvær</a> is licensed under CC BY 2.0</a> GitLab Major Security Update for CVE-2016-9469 2016-11-30T00:00:00+00:00 On Monday, December 5th, 2016 at 3:59pm PST (23:59 UTC), we will publish a major GitLab security update to address CVE-2016-9469, a denial-of-service and data corruption vulnerability. More details will be forthcoming on our blog</a>, including which versions of GitLab are affected. We recommend installations running affected versions to upgrade immediately. Please forward this alert to the appropriate people at your organization and have them subscribe to Security Notices</a>. Setting Up GitLab CI for Android Projects 2016-11-30T00:00:00+00:00 Have you ever accidentally checked in a typo that broke your Android build or unknowingly broke an important use case with a new change? Continuous Integration is a way to avoid these headaches, allowing you to confirm that changes to your app compile, and your tests pass before they're merged in. GitLab CI</a> is a wonderful Continuous Integration</a> built-in solution, and in this post we'll walk through how to setup a basic config file (.gitlab-ci.yml</code>) to ensure your Android app compiles and passes unit and functional tests. We assume that you know the process of creating an Android app, can write and run tests locally, and are familiar with the basics of the GitLab UI. Our Sample Project</h2> Here's the sample project</a> we'll be working with today. It's very simple. The app allows you to input two numbers, and then click "Calculate" to view the sum in a separate Activity. This is of course a very silly way to structure an app, but it allows us to write some clear examples of different kinds of tests. Unit Tests</h3> Unit tests</a> are the fundamental tests in your app testing strategy, from which you can verify that the logic of individual units is correct. They are a fantastic way to catch regressions when making changes to your app. They run directly on the Java Virtual Machine (JVM), so you don't need an actual Android device to run them. If you already have working unit tests, you shouldn't have to make any adjustments to have them work with GitLab CI. You can see some example unit tests in the sample app</a>. The sample doesn't use Robolectric</a>, but nothing stops you from doing so. Functional Tests</h3> Functional tests</a>, sometimes called UI tests or emulator tests, are great for those times when unit tests aren't practical. They are often used when you want to test a distinct user path that would be difficult to unit test. In our sample app</a>, we test the path of a user inputting numbers, pressing "Calculate," and seeing the result in the next Activity. Functional tests run on an actual Android device or emulator and can therefore be slow to execute, meaning that are typically only used when other testing methods aren't sufficient. Because functional tests run on an actual Android device or emulator, they tend to be finnicky. Any number of things could happen to screw up the test, including the screen locking. To help prevent this, the sample project includes a base class</a> for tests to ensure the screen is unlocked when the tests are run. The base class contains this @Before</code>-annotated method, meaning that it is run before each of your tests: @Before public void setup() { // Unlock the screen if it's locked UiDevice device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation()); try { device.wakeUp(); } catch (RemoteException e) { e.printStackTrace(); } // Set the flags on our activity so it'll appear regardless of lock screen state final Activity activity = getActivityRule().getActivity(); Runnable wakeUpDevice = new Runnable() { public void run() { activity.getWindow().addFlags(WindowManager.LayoutParams.FLAG_TURN_SCREEN_ON | WindowManager.LayoutParams.FLAG_SHOW_WHEN_LOCKED | WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON); } }; activity.runOnUiThread(wakeUpDevice); } </code></pre> Now that we've got the project setup, let's look at how we integrate GitLab CI. Setting Up GitLab CI</h2> We want to be able to configure our project so that our app is built, and it has both the unit and functional tests run upon check-in. To do so, we have to create our GitLab CI config file, called .gitlab-ci.yml</code>, and place it in the root of our project. So, first things first: If you're just here for a snippet to copy-paste, here is a .gitlab-ci.yml</code> that will build and test your app: image: openjdk:8-jdk variables: ANDROID_COMPILE_SDK: "25" ANDROID_BUILD_TOOLS: "24.0.0" ANDROID_SDK_TOOLS: "24.4.1" before_script: - apt-get --quiet update --yes - apt-get --quiet install --yes wget tar unzip lib32stdc++6 lib32z1 - wget --quiet --output-document=android-sdk.tgz https://dl.google.com/android/android-sdk_r${ANDROID_SDK_TOOLS}-linux.tgz - tar --extract --gzip --file=android-sdk.tgz - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter android-${ANDROID_COMPILE_SDK} - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter platform-tools - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter build-tools-${ANDROID_BUILD_TOOLS} - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-android-m2repository - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-google_play_services - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-m2repository - export ANDROID_HOME=$PWD/android-sdk-linux - export PATH=$PATH:$PWD/android-sdk-linux/platform-tools/ - chmod +x ./gradlew stages: - build - test build: stage: build script: - ./gradlew assembleDebug artifacts: paths: - app/build/outputs/ unitTests: stage: test script: - ./gradlew test functionalTests: stage: test script: - wget --quiet --output-document=android-wait-for-emulator https://raw.githubusercontent.com/travis-ci/travis-cookbooks/0f497eb71291b52a703143c5cd63a217c8766dc9/community-cookbooks/android-sdk/files/default/android-wait-for-emulator - chmod +x android-wait-for-emulator - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter sys-img-x86-google_apis-${ANDROID_COMPILE_SDK} - echo no | android-sdk-linux/tools/android create avd -n test -t android-${ANDROID_COMPILE_SDK} --abi google_apis/x86 - android-sdk-linux/tools/emulator64-x86 -avd test -no-window -no-audio & - ./android-wait-for-emulator - adb shell input keyevent 82 - ./gradlew cAT </code></pre> Source</a> Well, that's a lot of code! Let's break it down. Understanding .gitlab-ci.yml</code></h3> Defining the Docker Image</h4> image: openjdk:8-jdk </code></pre> This tells GitLab Runners</a> (the things that are executing our build) what Docker image</a> to use. If you're not familiar with Docker</a>, the TL;DR is that Docker provides a way to create a completely isolated version of a virtual operating system running in it’s own container</a>. Anything running inside the container thinks it has the whole machine to itself, but in reality there can be many containers running on a single machine. Unlike full virtual machines, Docker containers are super fast to create and destroy, making them great choices for setting up temporary environments for building and testing. This Docker image (openjdk:8-jdk</code>)</a> works perfectly for our use case, as it is just a barebones installation of Debian with Java pre-installed. We then run additional commands further down in our config to make our image capable of building Android apps. Defining Variables</h4> variables: ANDROID_COMPILE_SDK: "25" ANDROID_BUILD_TOOLS: "24.0.0" ANDROID_SDK_TOOLS: "24.4.1" </code></pre> These are variables we'll use throughout our script. They're named to match the properties you specify in your app's build.gradle</code></a>. ANDROID_COMPILE_SDK</code> is the version of Android you're compiling with. It should match compileSdkVersion</code>.</li> ANDROID_BUILD_TOOLS</code> is the version of the Android build tools you are using. It should match buildToolsVersion</code>.</li> ANDROID_SDK_TOOLS</code> is a little funny. It's what version of the command line tools we're going to download from the official site</a>. So, that number really just comes from the latest version available there.</li> </ul> Installing Packages</h4> before_script: - apt-get --quiet update --yes - apt-get --quiet install --yes wget tar unzip lib32stdc++6 lib32z1 </code></pre> This starts the block of the commands that will be run before each job in our config. These commands ensure that our package repository listings are up to date, and it installs packages we'll be using later on, namely: wget</code>, tar</code>, unzip</code>, and some packages that are necessary to allow 64-bit machines to run Android's 32-bit tools. Installing the Android SDK</h4> - wget --quiet --output-document=android-sdk.tgz https://dl.google.com/android/android-sdk_r${ANDROID_SDK_TOOLS}-linux.tgz - tar --extract --gzip --file=android-sdk.tgz - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter android-${ANDROID_COMPILE_SDK} - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter platform-tools - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter build-tools-${ANDROID_BUILD_TOOLS} - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-android-m2repository - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-google_play_services - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter extra-google-m2repository </code></pre> Here we're downloading the Android SDK tools from their official location, using our ANDROID_SDK_TOOLS</code> variable to specify the version. Afterwards, we're unzipping the tools and running a series of android</code> commands to install the necessary Android SDK packages that will allow our app to build. Setting Up the Environment</h4> - export ANDROID_HOME=$PWD/android-sdk-linux - export PATH=$PATH:$PWD/android-sdk-linux/platform-tools/ - chmod +x ./gradlew </code></pre> Finally, we wrap up the before_script</code> section of our config with a few remaining tasks. First, we set the ANDROID_HOME</code> environment variable to the SDK location, which is necessary for our app to build. Next, we add the platform tools to our PATH</code>, allowing us to use the adb</code> command without specifying its full path, which is important when we run a downloaded script later. Finally, we ensure that gradlew</code> is executable, as sometimes Git will mess up permissions. Defining the Stages</h4> stages: - build - test </code></pre> Here we're defining the different stages</a> of our build. We can call these anything we want. A stage can be thought of as a group of jobs</a>. All of the jobs in the same stage happen in parallel, and all jobs in one stage must be completed before the jobs in the subsequent stage begin. We've defined two stages: build</code> and test</code>. They do exactly what you think: the build</code> stage ensures the app compiles, and the test</code> stage runs our unit and functional tests. Building the App</h4> build: stage: build script: - ./gradlew assembleDebug artifacts: paths: - app/build/outputs/ </code></pre> This defines our first job, called build</code>. It's the only job in the build</code> stage. It just builds the debug version of the app and makes the outputs of the build available for download via the artifacts</code> field. Running Unit Tests</h4> unitTests: stage: test script: - ./gradlew test </code></pre> This defines a job called unitTests</code> that runs during the test</code> stage. Nothing crazy here - we're just running unit tests. Running Functional Tests</h4> functionalTests: stage: test script: - wget --quiet --output-document=android-wait-for-emulator https://raw.githubusercontent.com/travis-ci/travis-cookbooks/0f497eb71291b52a703143c5cd63a217c8766dc9/community-cookbooks/android-sdk/files/default/android-wait-for-emulator - chmod +x android-wait-for-emulator - echo y | android-sdk-linux/tools/android --silent update sdk --no-ui --all --filter sys-img-x86-google_apis-${ANDROID_COMPILE_SDK} - echo no | android-sdk-linux/tools/android create avd -n test -t android-${ANDROID_COMPILE_SDK} --abi google_apis/x86 - android-sdk-linux/tools/emulator64-x86 -avd test -no-window -no-audio & - ./android-wait-for-emulator - adb shell input keyevent 82 - ./gradlew cAT artifacts: paths: - app/build/reports/androidTests/ </code></pre> This defines a job called functionalTests</code> that runs during the test</code> stage. Functional tests are a little tricky to setup. First, we download a script that will allow us to detect when an emulator has finished booting. Then, we download the emulator system image we're going to use and create an instance of it. Afterwards, we start the emulator, wait for it to finish booting using our downloaded script, use adb</code> to send a signal to unlock the screen, and run our tests. After running these tests, the generated test report is made available for download via the artifacts</code> field. Run Your new CI Setup</h2> After you've added your new .gitlab-ci.yml</code> file to the root of your directory, just push your changes and off you go! You can see your running builds in the Pipelines tab of your project. You can even watch your build execute live and see the runner's output, allowing you to easily debug problems. After your build is done, you can retrieve your build artifacts: First, click on your completed build:</li> </ul> Then, navigate to the Builds tab:</li> </ul> Lastly, click on the download button for your desired job:</li> </ul> Conclusion</h2> So, there you have it! You now know how to create a GitLab CI config that will ensure your app: Compiles</li> Passes unit tests</li> Passes functional tests</li> </ul> And allows you to access your build artifacts (like your APK</a>) afterwards. Enjoy your newfound app stability :) About Guest Author</h2> Greyson Parrelli</a> is an Android developer at Snap Inc. working on Snapchat</a>. Previously, he's worked on the YouTube</a>, Yahoo! Weather</a>, and Yahoo! Mail</a> Android apps.

About Guest Author</h2>
Greyson Parrelli</a> is an Android developer at Snap Inc. working on Snapchat</a>. Previously, he's worked on the YouTube</a>, Yahoo! Weather</a>, and Yahoo! Mail</a> Android apps.</p>

GitLab

GitLab 8.14.2 released

Enterprise Edition</h2>
Interested in GitLab Enterprise Edition? Check out the features exclusive to EE</a>.</p>
Access to GitLab Enterprise Edition is included with a subscription</a>. No time to upgrade GitLab yourself? Subscribers receive upgrade and installation services.</p>

How to Keep your Fork Up-To-Date with its Origin

How to explain GitLab to anyone

GitLab Major Security Update for CVE-2016-9469

Setting Up GitLab CI for Android Projects

GitLab

GitLab 8.14.2 released

Upgrade barometer</h2> This version has no migrations and should not require any downtime.</p>

How to Keep your Fork Up-To-Date with its Origin