How to sync Github to Gitlab

How to sync Github to Gitlab

I, like a lot of people who have used Git, started out using Github. But I became a bit frustrated by the lack of some features that Gitlab had, but Github didn’t (unlike many, the decision to switch to Gitlab wasn’t because of Microsoft’s takeover of Github).

However, very few online code editors worked with Gitlab, while many would work with Github. While it isn’t a big hassle, time spent doing manual tasks (i.e. uploading and downloading files) adds up. Although Gitlab has a web IDE, I prefer using a dark mode and it doesn’t have the functionality that some other IDEs (Codeanywhere and Gitpod, for example) have.

To solve this, I decided to sync my Github repositories to Gitlab. If I make a change on Github, it will be reflected on the Gitlab project.

Photo by Pankaj Patel on Unsplash

What you’re going to want to do is to sign up for Github, if you haven’t already. Create a repository on Github, or choose the one that you want to sync to Gitlab.

If you haven’t signed up for Gitlab, sign up now, choosing the “sign up with Github option”. If you’ve already signed up for Gitlab, go to your settings and find the button that says “connect to github”.

All the services that can be connected to Gitlab

Once you’ve connected your github and gitlab accounts, click the little + button to the left of the search bar. Click “new project”.

The new project area

You are then going to want to click on the tab that says “CI/CD for external repo”. Click “Connect repositories from Github.” Select your project (it can be a personal repo or a corporation repo). It will take a few minutes to sync, and then you’re done!

Please note that while changes on the github repo will be reflected on gitlab, if you change something on gitlab, it won’t be reflected on Github.

Enjoy!

— Limo

#github

What is GEEK

Buddha Community

How to Compare Multiple GitHub Projects with Our GitHub Stats tool

If you have project code hosted on GitHub, chances are you might be interested in checking some numbers and stats such as stars, commits and pull requests.

You might also want to compare some similar projects in terms of the above mentioned stats, for whatever reasons that interest you.

We have the right tool for you: the simple and easy-to-use little tool called GitHub Stats.

Let’s dive right in to what we can get out of it.

Getting started

This interactive tool is really easy to use. Follow the three steps below and you’ll get what you want in real-time:

1. Head to the GitHub repo of the tool

2. Enter as many projects as you need to check on

3. Hit the Update button beside each metric

In this article we are going to compare three most popular machine learning projects for you.

#github #tools #github-statistics-react #github-stats-tool #compare-github-projects #github-projects #software-development #programming

Reform: Form Objects Decoupled From Models In Ruby

Reform

Form objects decoupled from your models.

Reform gives you a form object with validations and nested setup of models. It is completely framework-agnostic and doesn't care about your database.

Although reform can be used in any Ruby framework, it comes with Rails support, works with simple_form and other form gems, allows nesting forms to implement has_one and has_many relationships, can compose a form from multiple objects and gives you coercion.

Full Documentation

Reform is part of the Trailblazer framework. Full documentation is available on the project site.

Reform 2.2

Temporary note: Reform 2.2 does not automatically load Rails files anymore (e.g. ActiveModel::Validations). You need the reform-rails gem, see Installation.

Defining Forms

Forms are defined in separate classes. Often, these classes partially map to a model.

class AlbumForm < Reform::Form
  property :title
  validates :title, presence: true
end

Fields are declared using ::property. Validations work exactly as you know it from Rails or other frameworks. Note that validations no longer go into the model.

The API

Forms have a ridiculously simple API with only a handful of public methods.

1. #initialize always requires a model that the form represents.
2. #validate(params) updates the form's fields with the input data (only the form, not the model) and then runs all validations. The return value is the boolean result of the validations.
3. #errors returns validation messages in a classic ActiveModel style.
4. #sync writes form data back to the model. This will only use setter methods on the model(s).
5. #save (optional) will call #save on the model and nested models. Note that this implies a #sync call.
6. #prepopulate! (optional) will run pre-population hooks to "fill out" your form before rendering.

In addition to the main API, forms expose accessors to the defined properties. This is used for rendering or manual operations.

Setup

In your controller or operation you create a form instance and pass in the models you want to work on.

class AlbumsController
  def new
    @form = AlbumForm.new(Album.new)
  end

This will also work as an editing form with an existing album.

def edit
  @form = AlbumForm.new(Album.find(1))
end

Reform will read property values from the model in setup. In our example, the AlbumForm will call album.title to populate the title field.

Rendering Forms

Your @form is now ready to be rendered, either do it yourself or use something like Rails' #form_for, simple_form or formtastic.

= form_for @form do |f|
  = f.input :title

Nested forms and collections can be easily rendered with fields_for, etc. Note that you no longer pass the model to the form builder, but the Reform instance.

Optionally, you might want to use the #prepopulate! method to pre-populate fields and prepare the form for rendering.

Validation

After form submission, you need to validate the input.

class SongsController
  def create
    @form = SongForm.new(Song.new)

    #=> params: {song: {title: "Rio", length: "366"}}

    if @form.validate(params[:song])

The #validate method first updates the values of the form - the underlying model is still treated as immutuable and remains unchanged. It then runs all validations you provided in the form.

It's the only entry point for updating the form. This is per design, as separating writing and validation doesn't make sense for a form.

This allows rendering the form after validate with the data that has been submitted. However, don't get confused, the model's values are still the old, original values and are only changed after a #save or #sync operation.

Syncing Back

After validation, you have two choices: either call #save and let Reform sort out the rest. Or call #sync, which will write all the properties back to the model. In a nested form, this works recursively, of course.

It's then up to you what to do with the updated models - they're still unsaved.

Saving Forms

The easiest way to save the data is to call #save on the form.

if @form.validate(params[:song])
  @form.save  #=> populates album with incoming data
              #   by calling @form.album.title=.
else
  # handle validation errors.
end

This will sync the data to the model and then call album.save.

Sometimes, you need to do saving manually.

Default values

Reform allows default values to be provided for properties.

class AlbumForm < Reform::Form
  property :price_in_cents, default: 9_95
end

Saving Forms Manually

Calling #save with a block will provide a nested hash of the form's properties and values. This does not call #save on the models and allows you to implement the saving yourself.

The block parameter is a nested hash of the form input.

  @form.save do |hash|
    hash      #=> {title: "Greatest Hits"}
    Album.create(hash)
  end

You can always access the form's model. This is helpful when you were using populators to set up objects when validating.

  @form.save do |hash|
    album = @form.model

    album.update_attributes(hash[:album])
  end

Nesting

Reform provides support for nested objects. Let's say the Album model keeps some associations.

class Album < ActiveRecord::Base
  has_one  :artist
  has_many :songs
end

The implementation details do not really matter here, as long as your album exposes readers and writes like Album#artist and Album#songs, this allows you to define nested forms.

class AlbumForm < Reform::Form
  property :title
  validates :title, presence: true

  property :artist do
    property :full_name
    validates :full_name, presence: true
  end

  collection :songs do
    property :name
  end
end

You can also reuse an existing form from elsewhere using :form.

property :artist, form: ArtistForm

Nested Setup

Reform will wrap defined nested objects in their own forms. This happens automatically when instantiating the form.

album.songs #=> [<Song name:"Run To The Hills">]

form = AlbumForm.new(album)
form.songs[0] #=> <SongForm model: <Song name:"Run To The Hills">>
form.songs[0].name #=> "Run To The Hills"

Nested Rendering

When rendering a nested form you can use the form's readers to access the nested forms.

= text_field :title,         @form.title
= text_field "artist[name]", @form.artist.name

Or use something like #fields_for in a Rails environment.

= form_for @form do |f|
  = f.text_field :title

  = f.fields_for :artist do |a|
    = a.text_field :name

Nested Processing

validate will assign values to the nested forms. sync and save work analogue to the non-nested form, just in a recursive way.

The block form of #save would give you the following data.

@form.save do |nested|
  nested #=> {title:  "Greatest Hits",
         #    artist: {name: "Duran Duran"},
         #    songs: [{title: "Hungry Like The Wolf"},
         #            {title: "Last Chance On The Stairways"}]
         #   }
  end

The manual saving with block is not encouraged. You should rather check the Disposable docs to find out how to implement your manual tweak with the official API.

Populating Forms

Very often, you need to give Reform some information how to create or find nested objects when validateing. This directive is called populator and documented here.

Installation

Add this line to your Gemfile:

gem "reform"

Reform works fine with Rails 3.1-5.0. However, inheritance of validations with ActiveModel::Validations is broken in Rails 3.2 and 4.0.

Since Reform 2.2, you have to add the reform-rails gem to your Gemfile to automatically load ActiveModel/Rails files.

gem "reform-rails"

Since Reform 2.0 you need to specify which validation backend you want to use (unless you're in a Rails environment where ActiveModel will be used).

To use ActiveModel (not recommended because very out-dated).

require "reform/form/active_model/validations"
Reform::Form.class_eval do
  include Reform::Form::ActiveModel::Validations
end

To use dry-validation (recommended).

require "reform/form/dry"
Reform::Form.class_eval do
  feature Reform::Form::Dry
end

Put this in an initializer or on top of your script.

Compositions

Reform allows to map multiple models to one form. The complete documentation is here, however, this is how it works.

class AlbumForm < Reform::Form
  include Composition

  property :id,    on: :album
  property :title, on: :album
  property :songs, on: :cd
  property :cd_id, on: :cd, from: :id
end

When initializing a composition, you have to pass a hash that contains the composees.

AlbumForm.new(album: album, cd: CD.find(1))

More

Reform comes many more optional features, like hash fields, coercion, virtual fields, and so on. Check the full documentation here.

Reform is part of the Trailblazer project. Please buy my book to support the development and learn everything about Reform - there's two chapters dedicated to Reform!

Security And Strong_parameters

By explicitly defining the form layout using ::property there is no more need for protecting from unwanted input. strong_parameter or attr_accessible become obsolete. Reform will simply ignore undefined incoming parameters.

This is not Reform 1.x!

Temporary note: This is the README and API for Reform 2. On the public API, only a few tiny things have changed. Here are the Reform 1.2 docs.

Anyway, please upgrade and report problems and do not simply assume that we will magically find out what needs to get fixed. When in trouble, join us on Gitter.

Full documentation for Reform is available online, or support us and grab the Trailblazer book. There is an Upgrading Guide to help you migrate through versions.

Attributions!!!

Great thanks to Blake Education for giving us the freedom and time to develop this project in 2013 while working on their project.

---

Author: trailblazer
Source code: https://github.com/trailblazer/reform
License:  MIT license

#ruby  #ruby-on-rails

GitHub vs GitLab: Difference Between GitHub and GitLab

GitHub vs GitLab - how are they different?
 

▶ TIME CODES:
00:00 Intro
00:32 What is Git?
01:10 What is GitHub?
01:28 What is GitLab?
01:46 Features of GitHub and GitLab
02:45 Interfaces
03:40 Popularity and growth
04:18 Summary of our comparison
04:39 Contact Jelvix

---

Difference Between GitLab and GitHub

GitLab: GitLab is a repository hosting manager tool that is developed by GitLab Inc and is used for the software development process. It provides a variety of management by which we can streamline our collaborative workflow for completing the software development lifecycle. It also allows us to import the repository from Google Code, Bitbucket, etc. 
Following are some features of GitLab: 

• Open-source community edition repository management platform.
• Easy Maintaining of a repository on a server.
• Offers tools like Group Milestones, Time Tracking and Issue Tracker, etc. for effective development.
• More Spontaneous User interface and authentication features.
• User Permission and Branch protection are enhanced.

GitHub: GitHub is a repository hosting service tool that features collaboration and access control. It is a platform for programmers to fix bugs together and host open-source projects. GitHub is designed for the developers and to help them track their changes into a project through the repository. 
Following are some features of GitHub: 

• Specifies milestones and labels to the projects.
• Comparison view between branches is allowed.
• GitHub Pages allows us to publish and host websites within GitHub.
• Syntax highlight feature.
• It allows third-party API integrations for bug tracking and cloud hosting.

Below is a table of differences between GitLab and GitHub: 

Parameters	GitLab	GitHub
Developed by	GitLab was developed by Dmitriy Zaporozhets and Valery Sizov.	GitHub was developed by Chris Wanstrath, Tom Preston-Werner, P. J. Hyett, and Scott Chacon.
Open-sourced	GitLab is open-source for community edition.	GitHub is not open source.
Public Repository	It allows users to make public repository.	It allows users to have unlimited free repository.
Private Repository	GitLab also provides free private repository.	GitHub allows users to have free private repository but with a maximum of three collaborators.
Navigation	GitLab provides the feature of navigation into the repository.	GitHub allows users to navigate usability.
Project Analysis	GitLab provides user to see project development charts.	GitHub doesn’t have this feature yet but they can check the commit history.
Advantages	GitLab is freely available and open is source for community editiona a It is a cloud-native application and is highly secure.	It helps us create an organized document for the project. It is used for sharing the work in front of the public.
Disadvantages	GitLab is available with many bugs and it makes the user experience sloppy. It is difficult to manage code reviews for first-timers.	There is a limited private repository. It supports only Git version control.
Company	It is owned by GitLab Inc.	It is owned by Microsoft Corporation.

#github #gitlab #programming #developer 

Stay Safe on GitHub: Security Practices to Follow

gthen Access Controls

Implementing proper access control is one of the best practices for enhancing security, not only on GitHub but in every other environment where code security is imperative.

GitHub offers several options that users can employ to reduce the risk of improper exposure. But to start with, it is important to employ the least privilege model where users are only granted necessary permissions.

Here are some basic access control guidelines that you should follow:

• Restrict the creation of repositories to prevent users from exposing organization information in public repositories.
• Enable branch protection and status checks to ensure users can merge commits or manipulate branches safely.
• Allow or disallow forking private repositories to ensure users do not expose or share organizational code with unauthorized parties.
• Revoke access for all inactive users who are no longer part of the contributors.
• Review access rights to your GitHub projects periodically.
• Ensure users do not share GitHub accounts or passwords.
• Ensure every contributor uses two-factor authentication on their account.
• Rotate personal access tokens and SSH keys

Never Store Credentials in Your GitHub Files

Leaking secrets to your GitHub repositories, either through code, configuration files, or commit messages, provides a gateway for attacks.

#tutorial #github #access control #software security #repository management #github issues #source code analysis #github apps #github enterprise #git best practices

Stay Safe on GitHub: Security Practices to Follow

GitHub is undoubtedly the largest and most popular social development platform in the world. According to its 2019 State of the Octoverse Report, GitHub is home to over 40 million, and the community keeps expanding every day.

As developers in this deeply interconnected community use open source code to build software, Github security should be a top priority. This is because extensive code re-use increases the risk of distributing vulnerabilities from one dependency or repository to another. As such, every contributor should focus on creating a secure development environment.

Here are eight security practices that GitHub users can follow to stay safe and protect their code:

Strengthen Access Controls

Implementing proper access control is one of the best practices for enhancing security, not only on GitHub but in every other environment where code security is imperative.

GitHub offers several options that users can employ to reduce the risk of improper exposure. But to start with, it is important to employ the least privilege model where users are only granted necessary permissions.

Here are some basic access control guidelines that you should follow:

• Restrict the creation of repositories to prevent users from exposing organization information in public repositories.
• Enable branch protection and status checks to ensure users can merge commits or manipulate branches safely.
• Allow or disallow forking private repositories to ensure users do not expose or share organizational code with unauthorized parties.
• Revoke access for all inactive users who are no longer part of the contributors.
• Review access rights to your GitHub projects periodically.
• Ensure users do not share GitHub accounts or passwords.
• Ensure every contributor uses two-factor authentication on their account.
• Rotate personal access tokens and SSH keys

#tutorial #github #access control #software security #repository management #github issues #source code analysis #github apps #github enterprise #git best practices