NETWAYS Web Services: GitLab CE Hosting

This entry is part of 5 in the series NETWAYS Web Services

GitLab CE HostingGitLab CE (Community Edition) ist die frei verfügbare Variante von GitLab, welche alle wichtigen Features von GitLab in einer Open Source Version vereint. GitLab bietet eine webbasierte Oberfläche für Softwareprojekte auf Basis der Versionsverwaltung git. Dazu verfügt GitLab über diverse Management und Bug-Tracking-Funktionalitäten, sowie mit GitLab CI ein System zur kontinuierlichen Integration.

NETWAYS bietet das Hosting von GitLab CE in unserer NETWAYS Web Services an. Wir übernehmen hier nicht nur die Installation und Konfiguration, sondern auch den kompletten Betrieb inkl. regelmäßiger Updates auf die aktuellste Version. Unser Angebot wird verteilt über zwei Rechenzentren in Nürnberg gehostet und betrieben. Somit stellen wir einen sicheren und zuverlässigen Service an einem (sehr schönen) Standort in Deutschland zur Verfügung.

GitLab CE

Alle GitLab CE Instanzen laufen isoliert in einem eigenen Container und alle nötigen Ressourcen sind exklusiv für Ihr Projekt reserviert. Und bei uns sind die GitLab Runner schon mit dabei!

Und wie gewohnt bei NWS – Sie können GitLab CE bei uns 30 Tage kostenfrei testen. Jetzt schnell anmelden!

 

Contributing to projects on GitHub

GitHub Logo

Today I want to share my workflow for contributing to projects hosted on GitHub because I believe it works very well for me and I regularly contribute to various projects. Of course most of this also applies to other hosted Git platforms like GitLab. It will not involve any Git magic as there are other posts to do that. So let’s use adding a check command to Icinga 2 as my example.

The obvious first step is finding the Git repository for the project and reading contribution guidelines because there are some projects which aren’t hosted on GitHub and some have additional requirements like submitting an issue in addition to a pull request. You should always familiarize yourself with and stick to those policies if you want your pull request to be accepted. For Icinga 2 there currently aren’t any additional project-specific guidelines.

Your next step is to create a fork on GitHub and clone the repository. So in the GitHub web interface click on “Fork” and select your own account (or company account as long as you are allowed to push). Once you’ve forked the repository you can check out a local copy using the following command:


git clone git@github.com/dgoetz/icinga2.git

Afterwards you should add another “remote” for the original Git repository in order to be able to update your own repository with changes from the upstream project:


cd icinga2/
git remote add upstream git@github.com:icinga/icinga2.git

After these initial steps you can create a Git branch for your feature or bug fix. Using the “master” branch for pull requests is strongly discouraged because things tend to get complicated once you have more than one pull request. Another recommendation is to use branch names that match the upstream repository’s style. This however is not a hard requirement:


git checkout -b feature/expand-check-foo

This also automatically switches to the newly-created branch which means you can now start to edit files for your pull request. Once you’re done you can add them to the Git index and create a commit. Typically upstream projects have guidelines for this, so do not forget to include documentation, make only one commit out of your work (perhaps by squashing) and so on.


vi itl/plugins-contrib.d/network-components.conf
vi doc/10-icinga-template-library.md
git add itl/plugins-contrib.d/network-components.conf doc/10-icinga-template-library.md
git commit -m "ITL: expanded check foo"

Afterwards push your commit to your forked repository and then create your pull request using the GitHub webinterface:


git push -u origin feature/expand-check-foo

When creating the pull request make sure to provide a detailed description of your changes and the reason why you feel that your pull request should be merged. Keep the setting checked to allow edits from maintainers. Depending on the project make sure to reference any related issues, fill in their pull request template or do whatever else they require for pull requests.

GitHub pull request

Typically once a pull request is created automated tests will be run and a review process by the project team will start, so it’s possible that you’ll be asked to make changes before your pull request is accepted. If this happens simply edit your branch to fix whatever problems were found during the review, amend your commit and force push it to your fork. This will also automatically update your pull request but you might want to provide a comment for the pull request as to what has changed:


vi doc/10-icinga-template-library.md
git add doc/10-icinga-template-library.md
git commit --amend -m "ITL: expanded check foo"
git push -f

Another commonly requested change is that you rebase your branch before the pull request is accepted. This usually happens when significant changes were made to the upstream repository while your pull request was waiting to be merged. In order to rebase your branch the following commands should be all you need, however in some cases you may also have to manually resolve conflicts:


git pull --rebase upstream master
git push -f

And of course you will sometimes want to create additional pull requests. For these make sure to start with a new branch based on the upstream repository:


git checkout master
git pull upstream master
git checkout -b fix/check-bar
...
git push -u origin fix/check-bar

So, this is it, this is my basic workflow for easy contributions on GitHub. I hope it helps you to get involved with your favorite projects and your fixes and features to get upstream. If you prefer to do all step in the command line, you can have a look at GitHub’s command-line wrapper for git hub. If you need more general Git knowledge I recommend the Git book and our training. If you need a GitLab system to play around, have a look at our NWS platform.

Netways Managed Services Status Page – Github is your friend

Unser neues Familienmitglied

Als neuestes Angebot für unsere Hosting-Kunden haben wir nun eine Wartungsseite ins Leben gerufen. Diese ist öffentlich sichtbar unter status.netways.de und soll über Wartungsintervalle unserer Systeme informieren.

Diese Informationen sind in Form eines Blogs aufbereitet und umfassen Meldungen zu Wartungsbeginn, Wartungsende, Verlaufsupdates sowie den betroffenen Systemen und Services.

Blick hinter die Kulissen

Es gibt natürlich sehr viele Varianten, eine Webseite mit Blog umzusetzen. Eines unserer Kriterien war, dass die Wartungsseite extern gehostet sein sollte, um auch bei Wartungen an Webservern oder eventuellen Ausfällen den Informationsfluss zum Kunden garantieren zu können. Des Weiteren sollten Posts schnell und mit Methoden erstellt werden, die das Team bereits im Einsatz hat. Recht schnell fiel die Entscheidung dann auf das Format Github Pages, das all dies nativ bietet.

Wie funktioniert Github Pages?

Github Pages bietet die Möglichkeit, in einem Repository eine Webseite zu erstellen, die unter der URL <username>.github.io online verfügbar ist. Die Struktur der Webseite ist frei wählbar und kann mit den üblichen Layout-Sprachen wie HTML und CSS erstellt werden. Änderungen an der Webseite und das Hinzfügen von Posts können zum einen über die Github-Webseite, aber auch wie gewohnt über die git-Kommandozeile durchgeführt werden.

Nun fragen sich wahrscheinlich viele, wo denn jetzt der Clou an Github Pages ist – Jekyll!

Jekyll ist die Engine, die für uns im Hintergrund den Blog erstellt und die Webseite aktualisiert, sobald ein neuer Post oder eine Änderung an einem bereits bestehenden Post erfolgt. Dies ist nativ in Github Pages eingebaut, so dass hier nichts installiert werden muss – es gilt nur, die von Jekyll erwarteten Konventionen einzuhalten. Dazu gehören z. B. die Directory-Struktur im Repository sowie die File-Namen der Blog-Posts. Damit Jekyll den Blog korrekt generieren kann, werden Layouts hinterlegt, so dass die Posts als schön formatierte Einträge auf der Webseite erscheinen. Mithilfe dieser Layouts kann Jekyll die in Markdown verfassten Inhalte der Posts interpretieren.

Github Pages steht jedem zur Verfügung, der einen Github-Account besitzt. Was man daraus macht, bleibt einem selbst überlassen – jedoch sollte man sich dieses Angebot nicht entgehen lassen.

Als Startpunkt für die Reise durch Github Pages ist das Tutorial von Jonathan McGlone sehr zu empfehlen:

Creating and Hosting a Personal Site on GitHub

Ich wünsche allen Interessierten viel Spaß beim Ausprobieren!

Monthly Snap November > Icinga 2 Director, OSMC, HW group Updates, AVTECH, Request Tracker, Foreman, Ceph, Git, Icinga 2 API, Braintower

SnspIn November, Thomas Gelf began with announcing the Icinga Director 1.2.0 release.

Isabel informs about new HW group Updates and the new Firmware for AVTECH Room Alert 3E.

Then Julia H. said thank you to our OSMC sponsors and wrote about why to join the OSMC Hackathon

Jennifer told us why we visualize while Markus Waldmüller presents the auto-provisioning with Foreman

Furthermore, Michael reviewed the PuppetConf in San Diego and told why Git Squash is magic.

Christian announced our availability of Request Tracker starter packages and Martin K. informed what to know about the Puppet Enterprise 3.8 End of Life

Towards the end of November, Tobias gave an Icinga 2 API Cheat Sheet, while Tim gave a Ceph training review.

Finally, Isabel wrote about the new Braintower Software and Updates.