Add gitlab account android studio

Setting up GitLab CI for Android projects

Note: This is a new version of a previously published blog post, updated for the current Android API level (28). Thanks Grayson Parrelli for authoring the original post!

Have you ever accidentally checked on 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/CD is a wonderful Continuous Integration built-in solution, and in this post we’ll walk through how to set up a basic config file ( .gitlab-ci.yml ) 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

We’ll be working with a real-world open source Android project called Materialistic to demonstrate how easy it is to get up and running with GitLab CI for Android. Materialistic currently uses Travis CI with GitHub, but switching over is a breeze. If you haven’t seen Materialistic before, it’s a fantastic open source Android reader for Hacker News.

Testing

Unit tests 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. Materialistic uses Robolectric for tests, Jacoco for coverage, and also has a linting pass. We’ll get all of these easily running in our .gitlab-ci.yml example except for Jacoco, since that requires a secret token we do not have — though I will show you how to configure that in your own projects.

Setting up GitLab CI

We want to be able to configure our project so that our app is built, and it has the complete suite of tests run upon check-in. To do so, we have to create our GitLab CI config file, called .gitlab-ci.yml , 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 that will build and test the Materialistic app:

Well, that’s a lot of code! Let’s break it down.

Understanding .gitlab-ci.yml

Defining the Docker Image

This tells GitLab Runners (the things that are executing our build) what Docker image to use. If you’re not familiar with Docker, the TL;DR is that Docker provides a way to create a completely isolated version of a virtual operating system running in its own container. 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 ) 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

These are variables we’ll use throughout our script. They’re named to match the properties you would typically specify in your app’s build.gradle .

• ANDROID_COMPILE_SDK is the version of Android you’re compiling with. It should match compileSdkVersion .
• ANDROID_BUILD_TOOLS is the version of the Android build tools you are using. It should match buildToolsVersion .
• ANDROID_SDK_TOOLS is a little funny. It’s what version of the command line tools we’re going to download from the official site. So, that number really just comes from the latest version available there.

Installing packages

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 , tar , unzip , and some packages that are necessary to allow 64-bit machines to run Android’s 32-bit tools.

Installing the Android SDK

Here we’re downloading the Android SDK tools from their official location, using our ANDROID_SDK_TOOLS variable to specify the version. Afterwards, we’re unzipping the tools and running a series of sdkmanager commands to install the necessary Android SDK packages that will allow our app to build.

Setting up the environment

Finally, we wrap up the before_script section of our config with a few remaining tasks. First, we set the ANDROID_HOME environment variable to the SDK location, which is necessary for our app to build. Next, we add the platform tools to our PATH , allowing us to use the adb command without specifying its full path, which is important when we run a downloaded script later. Next, we ensure that gradlew is executable, as sometimes Git will mess up permissions.

The next command yes | android-sdk-linux/tools/bin/sdkmanager —licenses is responsible for accepting the SDK licenses. Because the unix yes command results in an EPIPE error once the pipe is broken (when the sdkmanager quits normally), we temporarily wrap the command in +o pipefile so that it does not terminate script execution when it fails.

Defining the stages

Here we’re defining the different stages of our build. We can call these anything we want. A stage can be thought of as a group of jobs. 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 and test . They do exactly what you think: the build stage ensures the app compiles, and the test stage runs our unit and functional tests.

Building the app

This defines our first job, called build . It has two parts — a linter to ensure that the submitted code is up to snuff, and the actual compilation of the code (and configuration of the artifacts that GitLab should expect to find). These are run in parallel for maximum efficiency.

Running tests

This defines a job called debugTests that runs during the test stage. Nothing too crazy here about setting something simple like this up!

If we had wanted to get Jacoco also working, that would be very straightforward. Simply adding a section as follows would work — the only additional thing you’d need to do is add a secret variable containing your personal COVERALLS_REPO_TOKEN :

Run your new CI setup

After you’ve added your new .gitlab-ci.yml 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 debug problems easily.

After your build is done, you can retrieve your build artifacts:

• First, click on your completed build, then navigate to the Jobs tab:

From here, simply click on the download button to download your build artifacts.

Conclusion

So, there you have it! You now know how to create a GitLab CI config that will ensure your app:

• Compiles
• Passes tests
• Allows you to access your build artifacts (like your APK) afterwards.

You can take a look at my local copy of the Materialistic repository, with everything up and running, at this link

Enjoy your newfound app stability 🙂

Master your CI/CD

Watch this webcast and learn to deliver faster with CI/CD.

Источник

Русские Блоги

Подробное объяснение Git — в сочетании с GitLab в Android Studio

1. Введение

Предыдущие инструменты управления версиями проекта используются SVN, теперь заменены GIT, а платформу хостинга проекта является GitLab. Хотя GitHub часто использует GitHub, используются несколько ветвей, потому что они написаны, они не используют разработку и выпуск, тег тем, поэтому вот также использование Git. Эта статья все еще будет собрасна и легко понять в соответствии с моим предыдущим стилем письма, и весь процесс должен работать, цель — понять для начинающих.

2. ВВЕДЕНИЕ

• Git: GIT — это распределенная система управления версией с открытым исходным кодом, которая может быть эффективно решена с небольшого до очень большой версии проекта. Проще говоря, это инструмент для управления версиями проекта.
• GitLab: GitLab — это проект с открытым исходным кодом, использующий систему управления складом с GIT в качестве инструмента управления кодом, а также создавать веб-сервисы на этой основе. Проще говоря, природа Gitlab такая же, как GitHub, который используется для хранения склада проекта.

3. Подготовьте git.

3.1 Установка Git.

Скачать адрес: http://git-scm.com/download/
Шаги установки: Дважды щелкните монтаж, нажмите опцию по умолчанию, чтобы пройти весь путь.
После завершения установки найдите «Git» -> «Git Bash» в меню «Пуск», как показано ниже, что показано, что установка GIT успешна!

3.2 Информация о конфигурации

Введите имя пользователя и адрес электронной почты в командной строке изображения

Параметр -Global в команде указывает, что все склады Git на этой машине будут использовать эту конфигурацию.

3.3 Настройка Git в Android Studio

4. Gitlab.

4.1 Зарегистрировать учетную запись

Возьмите платеж, когда вы зарегистрируете свою учетную запись.
Если вы зарегистрируете свою учетную запись, вы напомните следующую ошибку.

Это потому, что код подтверждения требуется для проверки кода, который является ReCAPTCHA, является графическим кодом подтверждения. Но этот проверки должен быть пополнен, прежде чем вы сможете его увидеть, иначе вы всегда зарегистрированы. Фигура:

4.2 Клавиши конфигурации учетной записи GitLab SSH

4.2.1 Во-первых необходимо проверить, есть ли ваш компьютер SSH-ключи

В пользователе Git Bash введите следующий код:

Существует существование существования, и существование можно игнорировать, и этап 4.2.2 игнорируется, а прямой доступ к этапу 4.2.3

4.2.2 Создание клавиш SSH

В пользователе Git Bash введите следующий код:

Затем следуйте напоминанию, как показано ниже:
Первый ввод представляет местоположение магазина клавиш, и вы можете нажать клавишу Enter по умолчанию. Второй и третий ENTER представляют пароль для ввода, когда требуется Push-файл. Если пароль не требуется, нажимайте клавишу Enter по умолчанию, а нижняя информация создана, а создание успешно!

4.2.3 Клавиши конфигурации GitLab SSH

4.3 Создание проекта

5. Android Studio использует Git

5.1 Загрузить проект в GitLab

Местные созданные проекты для WildMagit

5.1.1 Настройка игнорирования файлов

При нормальных обстоятельствах мы должны изменить /.idea/workspace.xml под корнем корня проекта. EDEA, остальные без особых требований будут использоваться по умолчанию. следующим образом:

Перед фиксацией:
После модификации:

5.1.2 Инициализация Местный Git Warehouse

5.1.3 Установка местного склада Git была связана с удаленным складом

Откройте папку Project и открыть Git Bash в этой папке. После ввода следующую команду вы будете связаны с удаленным складом от имени местного склада Git.

Определенные шаги показаны ниже:

Где [email protected]: wildma / wildmagit.git — это удаленный адрес нашего проекта, может скопировать проект перед нашим проектом, следующим образом:

image.png

5.1.4 Добавление документов

5.1.5 Подача

5.1.6 Нажмите файлы на удаленный склад

5.2 от GitLab на проекте клона

Наконец, заполните соответствующую информацию, как показано ниже:

• URL-адрес репозитория Git: заполните адрес проекта, просто реплицированный
• Родительский каталог: путь проекта
• Название каталога: имя папки проекта

После нажатия клона проект вниз!

5.3 Управление филиалом

5.3.1 Филиал Стратегия

В реальном развитии мы будем использовать много филиалов. Вот использование каждой ветви.

• Мастер филиал: самая стабильная ветвь, сохранить версию, которая должна быть освобождена, и не делает никаких разработок на ветке.
• Деве ветви: Разработайте ветви, сохраните последний код, обычно разработанный на этой ветке. Когда версия завершена, объедините в главную ветку, а затем отпустите его в главной ветви.
• Ошибка BUG: Используйте для ремонта ветви ошибки, обычно является онлайн-версией ошибки, создать новую филиал ошибки от главной ветви, чтобы исправить исправления ошибок, исправить слияние на ветку ветки и ветви (гарантировать ветку С синхронизацией ветви DEV ветвь ошибки затем удаляется.

В реальном развитии я в основном использую эти три филиала. Конечно, все отличаются, а некоторые люди подразделяют власть филиала, прогноз филиалов. Основная ветвь и ветвь DEV должны быть подталкиваться на расстояние. Для остальных участников могут развиваться вместе, филиал ошибки помещается локально, вы можете восстановить ошибку, чтобы удалить ее.

5.3.2 Операция филиала

Нажмите на VCS в верхней части студии Android в верхней части строки меню -> Git -> Филиалы . как показано:

Затем выберите «Новая ветвь», введите имя ветви, например «dev», как показано на рисунке: Нажмите OK, создается ветвь Dev и переключается в ветку по умолчанию. Повторите вышеуказанные шаги, чтобы увидеть текущий раздел «Дисплей ветви», как показано:

Нажмите ветку на удаленный

В это время мы изменили контент на ветви DEV, а затем отодвинули представленный файл на удаленный склад в соответствии с предыдущим документом представления (шаг 5.1.5) (этап 5.1.6). Фигура:

Нажмите на кнопку, затем вы можете увидеть ветвь Dev, мы просто нажали на GitLab, как показано:

Версия V1.0, разработанная на ветви DEV, и код объединяется в Master. Из-за текущей ветви DEV необходимо переключиться на ветку MASTER, нажмите на VCS в верхней части студии Android в верхней части строки меню, откройте окно ветвей GIT, затем выберите Master-> от локального Бар ветви. Происхождение / мастер, затем нажмите Checkout. Фигура:

Третий шаг был переключен на Master, а теперь филиал сливается. Нажмите на VCS -> Git -> Ветви . откройте окно GIT ветви, затем выберите «Происхождение / DEV» под удаленной веткой, а затем нажмите MERGE. Фигура:

В это время я обнаружил, что мастер-филиал не слился на модификацию ветви DEV на ветке магистра. Это было потому, что содержание дистанционного ветви DEV было только объединено в местную ветвь магистратуры, а местная ветвь магистратуры не толкнула К расстоянию и толчко можно быть о

Рисунок:

В это время я обнаружил, что главная ветвь на Gitlab была последовательной с филиалом Dev. А потом упакуйте последний ветвь Master!

Удалить филиал
Удалить локальные ветви:

Нажмите на VCS -> Git -> Филиалы . откройте окно GIT ветви, выберите локальное окно Детея, выберите «Удалить». Фигура:

Удалить удаленную ветку:

Нажмите на VCS -> Git -> Филиалы . откройте окно GIT ветви, выберите дистанционную ветку Dev, выберите «Удалить». Фигура:

5.4 Тег (тег) Управление

Этикетка обычно используется для течения версии выпуска, например, вы выпустили версию V1.0, на этот раз вы играете в тег V1.0, в основном для легко просмотра и управления версией кода.

Нажмите на VCS в верхней части студии Android в верхней части строки меню . как показано:

Затем заполните название тега и информацию о теге, нажмите Создать тег, чтобы создать локальную метку. Где Commit может заполнить идентификатор предыдущей записи подачи, он указан на тег на представление. Если вы не заполните тег на последнем фиксации. Фигура:

Нажмите на этикетку на удаленный
Нажмите на VCS в верхней части студии Android в верхней части строки меню -> Git -> Push . как показано:

Затем я всплываю нажатую кнопку, выберите толкающие теги и нажмите кнопку, чтобы нажать на пульт дистанционного управления. Фигура:

Наконец, вы можете увидеть тег, который только что был создан, как показано на рисунке:

Код заказа для метки

Нажмите на VCS в верхней части студии Android в верхней части строки меню -> Git -> Филиалы . как показано:

Затем выберите контрольную тег или редакцию . наконец, заполните имя тега в окне всплывающего окна. Фигура:

1. Удалить ярлык
   Вы нашли работу удаления тегов в Android Studio, поэтому используйте команду git здесь. (Я обнаружил мои друзья, чтобы сказать мне)

Источник