Tag Archives: github

Set github actions for you repo

If you want to run tests/linters against you golang project, place something like the example below in .github/workflows/somename.yml to your project:

name: ci-cd

on:
  push:
    branches:
      - '**'

env:
  GONOSUMDB: "github.com/<your-organization>"
  GOPRIVATE: "github.com/<your-organization>"
jobs:
  ci-cd:
    strategy:
      matrix:
        go-version: [ 1.16.x ]
    runs-on: ubuntu-latest
    steps:
      - name: Install Go
        uses: actions/setup-go@v2
        with:
          go-version: ${{ matrix.go-version }}
      - name: Write .netrc for private go modules
        env:
          NETRC_USER: ${{ secrets.NETRC_USER }}
          NETRC_PASS: ${{ secrets.NETRC_PASS }}
        run: echo "machine github.com login ${{ secrets.NETRC_USER }} password ${{ secrets.NETRC_PASS }}" > $HOME/.netrc
      - name: Checkout the code
        uses: actions/checkout@master
        with:
          fetch-depth: 1
      - name: Run Makefile::ci-cd-check
        run: make ci-cd-check

name: ci-cd

on:

push:

branches:

- '**'

env:

GONOSUMDB: "github.com/<your-organization>"

GOPRIVATE: "github.com/<your-organization>"

jobs:

ci-cd:

strategy:

matrix:

go-version: [ 1.16.x ]

runs-on: ubuntu-latest

steps:

- name: Install Go

uses: actions/setup-go@v2

with:

go-version: ${{ matrix.go-version }}

- name: Write .netrc for private go modules

env:

NETRC_USER: ${{ secrets.NETRC_USER }}

NETRC_PASS: ${{ secrets.NETRC_PASS }}

run: echo "machine github.com login ${{ secrets.NETRC_USER }} password ${{ secrets.NETRC_PASS }}" > $HOME/.netrc

- name: Checkout the code

uses: actions/checkout@master

with:

fetch-depth: 1

- name: Run Makefile::ci-cd-check

run: make ci-cd-check

Good article on that — https://github.com/mvdan/github-actions-golang

Publish subdirectory of a project to gh-pages

If your build is located at ./build, then do this:

git subtree push --prefix build origin gh-pages

1	git subtree push --prefix build origin gh-pages

More details here — https://gist.github.com/cobyism/4730490

Git-subtree для деплоя сайта на github-pages

Возьмём для примера проект https://github.com/bullgare/lzd_cllinics. Сборка для деплоя расположена в директории deploy/, и эта директория находится под контролем версий. Чтобы статический сайт был доступен по адресу http://bullgare.github.io/lzd_cllinics/, нужно содержимое этой директории запушить в отдельную ветку gh-pages. Проще всего сделать это так:

git subtree push --prefix deploy origin gh-pages

1	git subtree push --prefix deploy origin gh-pages

Эта команда сделает push закоммиченной директории deployв ветку gh-pages, что нам и нужно. …

Git: несколько разных ключей для одного хоста на примере bitbucket.org

Всё очень просто, достаточно прописать в ssh-конфиге алиасы:

Host work-bitbucket.org
 HostName bitbucket.org
 IdentityFile ~/.ssh/workid
Host personal-bitbucket.org
 HostName bitbucket.org
 IdentityFile ~/.ssh/personalid

Host work-bitbucket.org

HostName bitbucket.org

IdentityFile ~/.ssh/workid

Host personal-bitbucket.org

HostName bitbucket.org

IdentityFile ~/.ssh/personalid

И затем поправить путь к репозиторию гита:

git remote set-url origin git@work-bitbucket.org:repo_name.git

1	git remote set-url origin git@work-bitbucket.org:repo_name.git

https://confluence.atlassian.com/bitbucket/configure-multiple-ssh-identities-for-gitbash-mac-osx-linux-271943168.html

Как Github логирует клиентские ошибки (Haystack)

http://githubengineering.com/browser-monitoring-for-github-com/ Ничего сверхнового в идеях нет, есть наглядная картинка:

Gitlab flow

Github flow для gitlab. Как это выглядит. Есть центральный репозиторий http://gitlab.lan/group/repo_name. Каждый разработчик создаёт себе свой fork, в котором и производится работа (например, http://gitlab.lan/bullgare/repo_name). Результаты работы push-атся ведётся в своём репозитории (для этого нужно, чтобы git remote origin смотрел на gitlab@gitlab.lan:bullgare/repo_name.git). Также нужно добавить основной репозиторий вторым удалённым репозиторием

git remote add upstream gitlab@gitlab.lan:bullgare/repo_name.git

1	git remote add upstream gitlab@gitlab.lan:bullgare/repo_name.git

Перед началом работы по фиче …

Github Flow

По сравнению с git flow всё проще. Создаётся fork, разработка фичи ведётся в отдельной ветке. Потом создаётся pull request (merge request для gitlab), опционально назначаются ответственные за merge, в процессе обсуждений может продолжаться работа в ветке (изменения будут автоматически добавлены к request). После одобрения ветка мёржится в мастер/главную ветку https://guides.github.com/introduction/flow/index.html

Github: подготовка к pull-request

https://help.github.com/articles/fork-a-repo — как создать fork. Тут всё просто — в дополнение к очевидным вещам нужно добавить ещё один источник:

git remote add upstream https://github.com/octocat/.....

1	git remote add upstream https://github.com/octocat/.....

https://help.github.com/articles/syncing-a-fork — как продолжать обновлять из оригинального репозитория. Тут всё тоже не очень сложно:

git fetch upstream
git checkout master
git merge upstream/master

git fetch upstream

git checkout master

git merge upstream/master

Если ветка уже создана, то

git checkout <ветка>
git rebase master

1 2	git checkout <ветка> git rebase master

Чтобы поменять (если нужно) url до origin:

git remote set-url origin git://new.url.here

1	git remote set-url origin git://new.url.here

https://blog.bullgare.com/2014/04/git-%D0%BF%D0%B5%D1%80%D0%B5%D0%BB%D0%B8%D1%82%D1%8C-%D0%BB%D0%BE%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9-%D1%80%D0%B5%D0%BF%D0%BE%D0%B8%D1%82%D0%BE%D1%80%D0%B8%D0%B9-%D0%B2-%D0%BD%D0%BE%D0%B2/

Хостинг статики на github

Чтобы создать для проекта сайт с его описанием вида http://bullgare.github.com/[проект]/, достаточно выполнить пару шагов отсюда: https://help.github.com/articles/creating-pages-with-the-automatic-generator. Ещё можно почитать здесь — https://help.github.com/categories/20/articles