Tekton Pipeline Hello World Tutorial

Hello World Tutorial

Welcome to the Tekton Pipeline tutorial!

This tutorial will walk you through creating and running some simple
Tasks & Pipelinesand running them by creating
TaskRuns and PipelineRuns.

Before starting this tutorial, please install the Tekton CLI.

Note: This tutorial can be run on a local workstation

Task

The main objective of Tekton Pipelines is to run your Task individually or as a
part of a Pipeline. Every Task runs as a Pod on your Kubernetes cluster with
each step as its own container.

A Task defines the work that needs to be executed, for example the
following is a simple Task that will echo hello world:

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: echo-hello-world
spec:
  steps:
    - name: echo
      image: ubuntu
      command:
        - echo
      args:
        - "hello world"

The steps are a series of commands to be sequentially executed by the Task.

A TaskRun runs the Task you defined. Here is a simple example
of a TaskRun you can use to execute your Task:

1
2
3
4
5
6
7
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
  name: echo-hello-world-task-run
spec:
  taskRef:
    name: echo-hello-world

To apply the yaml files, use the following command:

1
kubectl apply -f <name-of-file.yaml>

To see the output of the TaskRun, use the following command:

1
tkn taskrun describe echo-hello-world-task-run

You will get an output similar to the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Name:        echo-hello-world-task-run
Namespace:   default
Task Ref:    echo-hello-world

Status
STARTED         DURATION    STATUS
4 minutes ago   9 seconds   Succeeded

Input Resources
No resources

Output Resources
No resources

Params
No params

Steps
NAME
echo

The status of type Succeeded shows that the Task ran successfully.

To see the actual outcome, use the following command:

1
tkn taskrun logs echo-hello-world-task-run

You will get an output similar to this:

1
[echo] hello world

Task Inputs and Outputs

In more common scenarios, a Task needs multiple steps with input and output
resources to process. For example a Task could fetch source code from a GitHub
repository and build a Docker image from it.

PipelineResources are used to define the artifacts that can be
passed in and out of a Task. There are a few system defined resource types ready
to use, and the following are two examples of the resources commonly needed.

The git resource represents a git repository with
a specific revision:

1
2
3
4
5
6
7
8
9
10
11
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: skaffold-git
spec:
  type: git
  params:
    - name: revision
      value: master
    - name: url
      value: https://github.com/GoogleContainerTools/skaffold #configure: change if you want to build something else, perhaps from your own local git repository.

The image resource represents the image to be
built by the Task:

1
2
3
4
5
6
7
8
9
apiVersion: tekton.dev/v1alpha1
kind: PipelineResource
metadata:
  name: skaffold-image-leeroy-web
spec:
  type: image
  params:
    - name: url
      value: gcr.io/<use your project>/leeroy-web #configure: replace with where the image should go: perhaps your local registry or Dockerhub with a secret and configured service account

The following is a Task with inputs and outputs. The input resource is a
GitHub repository and the output is the image produced from that source. The
args of the Task command support variable substitution so that the definition of Task is
constant and the value of parameters can change in runtime.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: build-docker-image-from-git-source
spec:
  inputs:
    resources:
      - name: docker-source
        type: git
    params:
      - name: pathToDockerFile
        type: string
        description: The path to the dockerfile to build
        default: /workspace/docker-source/Dockerfile
      - name: pathToContext
        type: string
        description:
          The build context used by Kaniko
          (https://github.com/GoogleContainerTools/kaniko#kaniko-build-contexts)
        default: /workspace/docker-source
  outputs:
    resources:
      - name: builtImage
        type: image
  steps:
    - name: build-and-push
      image: gcr.io/kaniko-project/executor:v0.14.0
      # specifying DOCKER_CONFIG is required to allow kaniko to detect docker credential
      env:
        - name: "DOCKER_CONFIG"
          value: "/builder/home/.docker/"
      command:
        - /kaniko/executor
      args:
        - --dockerfile=$(inputs.params.pathToDockerFile)
        - --destination=$(outputs.resources.builtImage.url)
        - --context=$(inputs.params.pathToContext)

Before you continue with the TaskRun you will have to
create a secret to push your image to your desired registry.

To do so, use the following command:

1
2
3
4
5
kubectl create secret docker-registry regcred \
                    --docker-server=<your-registry-server> \
                    --docker-username=<your-name> \
                    --docker-password=<your-pword> \
                    --docker-email=<your-email>

To be able to use this secret the TaskRun needs to use a ServiceAccount.

The ServiceAccount should look similar to this:

1
2
3
4
5
6
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tutorial-service
secrets:
  - name: regcred

You need to put your new ServiceAccount into action, to do so, use the following command:

1
kubectl apply -f <name-of-file.yaml>

Now you are ready for your first TaskRun.

A TaskRun binds the inputs and outputs to already defined PipelineResources,
sets values to the parameters used for variable substitution in addition to executing the
Task steps.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: tekton.dev/v1alpha1
kind: TaskRun
metadata:
  name: build-docker-image-from-git-source-task-run
spec:
  serviceAccountName: tutorial-service
  taskRef:
    name: build-docker-image-from-git-source
  inputs:
    resources:
      - name: docker-source
        resourceRef:
          name: skaffold-git
    params:
      - name: pathToDockerFile
        value: Dockerfile
      - name: pathToContext
        value: /workspace/docker-source/examples/microservices/leeroy-web #configure: may change according to your source
  outputs:
    resources:
      - name: builtImage
        resourceRef:
          name: skaffold-image-leeroy-web

To apply the yaml files use the following command, you need to apply the two
PipelineResources, the Task and TaskRun.

1
kubectl apply -f <name-of-file.yaml>

To see all the resource created so far as part of Tekton Pipelines, run the
command:

1
kubectl get tekton-pipelines

You will get an output similar to the following:

1
2
3
4
5
6
7
8
9
NAME                                                   AGE
taskruns/build-docker-image-from-git-source-task-run   30s

NAME                                          AGE
pipelineresources/skaffold-git                6m
pipelineresources/skaffold-image-leeroy-web   7m

NAME                                       AGE
tasks/build-docker-image-from-git-source   7m

To see the output of the TaskRun, use the following command:

1
tkn taskrun describe build-docker-image-from-git-source-task-run

You will get an output similar to the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
Name:        build-docker-image-from-git-source-task-run
Namespace:   default
Task Ref:    build-docker-image-from-git-source

Status
STARTED       DURATION     STATUS
2 hours ago   56 seconds   Succeeded

Input Resources
NAME            RESOURCE REF
docker-source   skaffold-git

Output Resources
NAME         RESOURCE REF
builtImage   skaffold-image-leeroy-web

Params
NAME               VALUE
pathToDockerFile   Dockerfile
pathToContext      /workspace/docker-source/examples/microservices/leeroy-web

Steps
NAME
build-and-push
create-dir-builtimage-wtjh9
git-source-skaffold-git-tck6k
image-digest-exporter-hlbsq

The status of type Succeeded shows the Task ran successfully and you
can also validate the Docker image is created in the location specified in the
resource definition.

If you run into issues, use the following command to receive the logs:

1
tkn taskrun logs build-docker-image-from-git-source-task-run

Pipeline

A Pipeline defines a list of Tasks to execute in order, while
also indicating if any outputs should be used as inputs of a following Task by
using the from field and also indicating
the order of executing (using the runAfter and from fields).
The same variable substitution you used in Tasks is also available in a Pipeline.

For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: tutorial-pipeline
spec:
  resources:
    - name: source-repo
      type: git
    - name: web-image
      type: image
  tasks:
    - name: build-skaffold-web
      taskRef:
        name: build-docker-image-from-git-source
      params:
        - name: pathToDockerFile
          value: Dockerfile
        - name: pathToContext
          value: /workspace/docker-source/examples/microservices/leeroy-web #configure: may change according to your source
      resources:
        inputs:
          - name: docker-source
            resource: source-repo
        outputs:
          - name: builtImage
            resource: web-image
    - name: deploy-web
      taskRef:
        name: deploy-using-kubectl
      resources:
        inputs:
          - name: source
            resource: source-repo
          - name: image
            resource: web-image
            from:
              - build-skaffold-web
      params:
        - name: path
          value: /workspace/source/examples/microservices/leeroy-web/kubernetes/deployment.yaml #configure: may change according to your source
        - name: yamlPathToImage
          value: "spec.template.spec.containers[0].image"

The above Pipeline is referencing a Task called deploy-using-kubectl which
can be found here:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: deploy-using-kubectl
spec:
  inputs:
    resources:
      - name: source
        type: git
      - name: image
        type: image
    params:
      - name: path
        type: string
        description: Path to the manifest to apply
      - name: yamlPathToImage
        type: string
        description:
          The path to the image to replace in the yaml manifest (arg to yq)
  steps:
    - name: replace-image
      image: mikefarah/yq
      command: ["yq"]
      args:
        - "w"
        - "-i"
        - "$(inputs.params.path)"
        - "$(inputs.params.yamlPathToImage)"
        - "$(inputs.resources.image.url)"
    - name: run-kubectl
      image: lachlanevenson/k8s-kubectl
      command: ["kubectl"]
      args:
        - "apply"
        - "-f"
        - "$(inputs.params.path)"

With the new Task inside of your Pipeline,
you need to give your ServiceAccount additional permissions to be able to execute the run-kubectl step.

First you have to create a new role, which you have to assign to your ServiceAccount,
to do so, use the following command:

1
2
3
kubectl create clusterrole tutorial-role \
               --verb=get,list,watch,create,update,patch,delete \
               --resource=deployments

Now you need to assign this new role tutorial-role to your ServiceAccount,
to do so, use the following command:

1
2
3
kubectl create clusterrolebinding tutorial-binding \
             --clusterrole=tutorial-role \
             --serviceaccount=default:tutorial-service

To run the Pipeline, create a PipelineRunas follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: tekton.dev/v1alpha1
kind: PipelineRun
metadata:
  name: tutorial-pipeline-run-1
spec:
  serviceAccountName: tutorial-service
  pipelineRef:
    name: tutorial-pipeline
  resources:
    - name: source-repo
      resourceRef:
        name: skaffold-git
    - name: web-image
      resourceRef:
        name: skaffold-image-leeroy-web

The PipelineRun will create the TaskRuns corresponding to each Task and
collect the results.

To apply the yaml files use the following command, you will need to apply the
deploy-task if you want to run the Pipeline.

1
kubectl apply -f <name-of-file.yaml>

While the Pipeline is running, you can see what exactly is happening, just use the following command:

1
tkn pipelinerun logs tutorial-pipeline-run-1 -f

To see the output of the PipelineRun, use the following command:

1
tkn pipelinerun describe tutorial-pipeline-run-1

You will get an output similar to the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Name:           tutorial-pipeline-run-1
Namespace:      default
Pipeline Ref:   tutorial-pipeline

Status
STARTED       DURATION   STATUS
4 hours ago   1 minute   Succeeded

Resources
NAME          RESOURCE REF
source-repo   skaffold-git
web-image     skaffold-image-leeroy-web

Params
No params

Taskruns
NAME                                               TASK NAME            STARTED       DURATION     STATUS
tutorial-pipeline-run-1-deploy-web-jjf2l           deploy-web           4 hours ago   14 seconds   Succeeded
tutorial-pipeline-run-1-build-skaffold-web-7jgjh   build-skaffold-web   4 hours ago   1 minute     Succeeded

The status of type Succeeded shows the Pipeline ran successfully, also
the status of individual Task runs are shown.

Local development

Known good configuration

Tekton Pipelines is known to work with:

  • Docker for Desktop. A known good
    configuration specifies six CPUs, 10 GB of memory and 2 GB of swap space.
  • These prerequisites.
  • Setting host.docker.local:5000 as an insecure registry with Docker for
    Desktop (set via preferences or configuration, see the
    Docker insecure registry documentation.
    for details)
  • Passing --insecure as an argument to Kaniko tasks lets us push to an
    insecure registry.
  • Running a local (insecure) Docker registry: this can be run with

docker run -d -p 5000:5000 --name registry-srv -e REGISTRY_STORAGE_DELETE_ENABLED=true registry:2

  • Optionally, a Docker registry viewer so we can check our pushed images are
    present:

docker run -it -p 8080:8080 --name registry-web --link registry-srv -e REGISTRY_URL=http://registry-srv:5000/v2 -e REGISTRY_NAME=localhost:5000 hyper/docker-registry-web

Images

  • Any PipelineResource definitions of image type should be updated to use the
    local registry by setting the url to
    host.docker.internal:5000/myregistry/<image name> equivalents
  • The KO_DOCKER_REPO variable should be set to localhost:5000/myregistry
    before using ko
  • You are able to push to host.docker.internal:5000/myregistry/<image name>
    but your applications (e.g any deployment definitions) should reference
    localhost:5000/myregistry/<image name>

Logging

  • Logs can remain in-memory only as opposed to sent to a service such as
    Stackdriver.
  • See docs on getting logs from Runs

Elasticsearch, Beats and Kibana can be deployed locally as a means to view logs:
an example is provided at
https://github.com/mgreau/tekton-pipelines-elastic-tutorials.

Experimentation

Lines of code you may want to configure have the #configure annotation. This
annotation applies to subjects such as Docker registries, log output locations
and other nuances that may be specific to particular cloud providers or
services.

The TaskRuns have been created in the following
order:

  1. tutorial-pipeline-run-1-build-skaffold-web - This runs the
    Pipeline Task build-skaffold-web first,
    because it has no from or runAfter clauses
  2. tutorial-pipeline-run-1-deploy-web - This runs deploy-web second, because
    its input web-image comes from
    build-skaffold-web (therefore build-skaffold-web must run before
    deploy-web).

ALL >>

Mac 初始化

xcode

1
xcode-select --install

homebrew

https://brew.sh/

1
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Install software

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# IDE
brew install zsh
brew install tmux
brew install python
brew install vim
brew install nodejs

# Shell
brew install hub

# CI/CD
brew install go
brew install kubernetes-cli
brew install kubernetes-helm
brew install kubectx

Google Drive

https://www.google.com/drive/download/

  • alfred
  • spectacle
  • shadowsocks-ng
  • karabiner
  • mailspring

vim

1
vim ~/.vimrc

ALL >>

JS 动态加载字体

Axios + FileReader

FileReader 对象允许Web应用程序异步读取存储在用户计算机上的文件（或原始数据缓冲区）的内容，使用 File 或 Blob 对象指定要读取的文件或数据。

File 对象是来自用户在一个 input 元素上选择文件后返回的 FileList 对象,也可以是来自由拖放操作生成的 DataTransfer 对象，或者来自 HTMLCanvasElement 上的 mozGetAsFile() API。

Blob 对象表示一个不可变、原始数据的类文件对象。Blob 表示的不一定是JavaScript原生格式的数据。File 接口基于Blob，继承了 blob 的功能并将其扩展使其支持用户系统上的文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
const woffUrl = chrome.extension.getURL('/libs/fonts/element-icons.woff');

axios.get(woffUrl, {
  responseType: 'blob',
}).then(data => {
  const reader = new FileReader();
  reader.readAsDataURL(data.data);
  reader.onloadend = _ => {
    const woffData = reader.result;

    const newStyle = document.createElement('style');
    newStyle.appendChild(document.createTextNode(`
      @font-face {
          font-family: element-icons;
          src: url(${woffData}) format("woff");
      }\
    `));
    document.head.appendChild(newStyle);
  };
});

ALL >>

记一次数组赋值导致的页面卡死

前言

一个很简单的功能直接导致页面卡死

1
2
3
const arr = [];
arr[4294967294] = 'arr';
arr.map(item => console.log(item));

尝试在控制台运行以上代码…

解析

JavaScript 使用一个32位整数，保存数组的元素个数。这意味着，数组成员最多只有 4294967295 个（232 - 1）个，也就是说length属性的最大值就是 4294967295。

1
2
3
4
5
6
7
8
9
10
11
var arr = ['a', 'b'];
arr.length // 2

arr[2] = 'c';
arr.length // 3

arr[9] = 'd';
arr.length // 10

arr[1000] = 'e';
arr.length // 1001

数组的遍历会从索引 0 开始一直到 length-1

所以，以下代码往往不可控

1
2
3
4
5
6
7
let key: number;

...

const arr = [];
arr[key] = ...
arr.map(item => ...);

对数组以一个 number 类型的变量作为 key 赋值后，再使用 map, forEach, for... 等来遍历数组时，由于 key 的值不可控，如果是数据库中的 主键id，那么在数据量小的时候发现不了什么异常，一旦数据量过大，浏览器直接就会卡死!

ALL >>

Ubuntu 内核升级

查看发布版本号

1
2
3
cat /etc/issue

lsb_release -a

查看内核版本号

1
2
3
4
5
# 内核信息
uname -sr

# 所有信息
uname -a

升级方式一

到官网kernel.ubuntu.com下载对应deb文件

列表

文件

下载 *all.deb 和所有 *generic*.deb 文件后，到对应文件夹下执行

1
sudo dpkg -i *.deb

我是64位操作系统所以选择的 amd64，32位的小伙伴选 i386即可

升级方式二（推荐）

查看需要更新的内核命令

1
apt-cache search linux

安装对应版本内核

1
sudo apt install linux-headers-5.0.8-050008-generic

install

安装完成后默认启动最新内核

1
2
# 查看内核启动顺序
grep menuentry /boot/grub/grub.cfg

卸载多余内核

1
sudo apt-get autoremove

ALL >>

Angular Router Reuse

序言

路由在切换时需要销毁当前组件，这在大多数情况下是符合预期的。但是有些时候在一些列表 + 详情的结构下，进入详情后再返回列表需要保留之前的列表状态，此时就需要缓存列表路由。

现有方案

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
// route-reuse.strategy.ts

import {
  RouteReuseStrategy,
  DefaultUrlSerializer,
  ActivatedRouteSnapshot,
  DetachedRouteHandle
} from '@angular/router';

export class SimpleReuseStrategy implements RouteReuseStrategy {

  _cacheRouters: { [key: string]: any } = {};

  shouldDetach(route: ActivatedRouteSnapshot): boolean {
    return !!route.data.keep;
  }

  store(route: ActivatedRouteSnapshot, handle: DetachedRouteHandle): void {
    this._cacheRouters[this._getCacheKey(route)] = {
      snapshot: route,
      handle: handle
    };
  }

  shouldAttach(route: ActivatedRouteSnapshot): boolean {
    return route.data.keep && !!this._cacheRouters[this._getCacheKey(route)];
  }

  retrieve(route: ActivatedRouteSnapshot): DetachedRouteHandle {
    if (!route.data.keep || !this._cacheRouters[this._getCacheKey(route)]) {
      return null;
    }
    return this._cacheRouters[this._getCacheKey(route)].handle;
  }

  shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
    return this._getCacheKey(future) === this._getCacheKey(curr);
  }

  _getCacheKey(route: ActivatedRouteSnapshot): string {
    return route['_routerState'].url;
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// app-routing.module.ts
import {
  RouteReuseStrategy,
  RouterModule,
} from '@angular/router';

@NgModule({
  imports: [
    RouterModule.forRoot(routes),
  ],
  providers: [{
    provide: RouteReuseStrategy,
    useClass: SimpleReuseStrategy,
  }],
  exports: [RouterModule]
})

export class AppRoutingModule { }
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
// 任意一个页面组件
import {
  NavigationEnd,
  Router,
} from '@angular/router';

constructor(
  private router: Router
) {
  this.router.events
    .filter((event) => event instanceof NavigationEnd)
    .subscribe((event: NavigationEnd) => {
      // 这里需要判断一下当前路由，如果不加的话，每次路由结束的时候都会执行这里的方法
      if (event.url.indexOf('currentRoute') > -1) {
        // 进入当前路由需要重新执行的操作
        ...
      }
    });
}

问题

同一父路由 下的子路由之间的跳转会重新初始化 parent component。翻了翻源代码这才找到了答案。

RouteReuseStrategy 抽象类

Provides a way to customize when activated routes get reused. code

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
export abstract class RouteReuseStrategy {
  /** Determines if this route (and its subtree) should be detached to be reused later */
  abstract shouldDetach(route: ActivatedRouteSnapshot): boolean;

  /**
   * Stores the detached route.
   *
   * Storing a `null` value should erase the previously stored value.
   */
  abstract store(route: ActivatedRouteSnapshot, handle: DetachedRouteHandle|null): void;

  /** Determines if this route (and its subtree) should be reattached */
  abstract shouldAttach(route: ActivatedRouteSnapshot): boolean;

  /** Retrieves the previously stored route */
  abstract retrieve(route: ActivatedRouteSnapshot): DetachedRouteHandle|null;

  /** Determines if a route should be reused */
  abstract shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean;
}

官方默认的 ReuseStrategy 如下

1
2
3
4
5
6
7
8
9
10
11
12
/**
 * Does not detach any subtrees. Reuses routes as long as their route config is the same.
 */
export class DefaultRouteReuseStrategy implements RouteReuseStrategy {
  shouldDetach(route: ActivatedRouteSnapshot): boolean { return false; }
  store(route: ActivatedRouteSnapshot, detachedTree: DetachedRouteHandle): void {}
  shouldAttach(route: ActivatedRouteSnapshot): boolean { return false; }
  retrieve(route: ActivatedRouteSnapshot): DetachedRouteHandle|null { return null; }
  shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
    return future.routeConfig === curr.routeConfig;
  }
}

对比发现 shouldReuseRoute 中的判断条件不一样。于是将原有代码做了一些调整

1
2
3
shouldReuseRoute(future: ActivatedRouteSnapshot, curr: ActivatedRouteSnapshot): boolean {
  return future.routeConfig === curr.routeConfig || this._getCacheKey(future) === this._getCacheKey(curr);
}

此时同一父路由下的子路由之间的跳转不会再初始化父组件了。

ALL >>

Hexo 插件 Gitment安装

Get Started

1. Install

1
<link rel="stylesheet" href="https://imsun.github.io/gitment/style/default.css">
1
<script src="https://imsun.github.io/gitment/dist/gitment.browser.js"></script>

or via npm:

1
$ npm i --save gitment
1
2
import 'gitment/style/default.css'
import Gitment from 'gitment'

2. Register An OAuth Application

Click here

注意 http 和 https

oauth

3. Render Gitment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
const gitment = new Gitment({
  id: 'Your page ID', // optional
  owner: 'Your GitHub ID',
  repo: 'The repo to store comments',
  oauth: {
    client_id: 'Your client ID',
    client_secret: 'Your client secret',
  },
  // ...
  // For more available options, check out the documentation below
})

gitment.render('comments')
// or
// gitment.render(document.getElementById('comments'))
// or
// document.body.appendChild(gitment.render())

FAQ

Error: Comments Not Initialized

出现这个错误一般有两个原因

  1. 没有登录
  2. OAuth配置有问题，检查一下回调是否正确

登录时浏览器弹出[Object ProgressEvent]

这个问题稍微复杂一点，简单一点的方案是直接替换 gitment.browser.js的路径

1
2
<link rel="stylesheet" href="//lovesoraliu.github.io/gitment/style/default.css">
<script src="//lovesoraliu.github.io/gitment/dist/gitment.browser.js"></script>

如果想要自己折腾的话略微有些麻烦，大致步骤如下

1. clone server

在自己服务器上clone gh-oauth-server, 执行

1
2
# 端口号默认是3000
npm start

启动 gitment server

2. clone gitment

fork gitment, clone fork的代码到本地，切到 gh-pages 分支

3. 修改url

将 https://gh-oauth.imsun.net 改为自己服务器的 http(s) + domain or ip + port。

1
2
3
4
5
6
7
8
9
10
11
_utils.http.post('https://gh-oauth.imsun.net', {
  code: code,
  client_id: client_id,
  client_secret: client_secret
}, '').then(function (data) {
  _this.accessToken = data.access_token;
  _this.update();
}).catch(function (e) {
  _this.state.user.isLoggingIn = false;
  alert(e);
});
1
2
3
4
5
6
7
8
9
10
11
_utils.http.post('https://gitment.soraliu.devlovesora.pro', {
  code: code,
  client_id: client_id,
  client_secret: client_secret
}, '').then(function (data) {
  _this.accessToken = data.access_token;
  _this.update();
}).catch(function (e) {
  _this.state.user.isLoggingIn = false;
  alert(e);
});

4. push代码 & 修改文件路径

将刚才的改动 push 至 github，再修改 gitment.browser.js 的url 即可

1
2
<link rel="stylesheet" href="//[username].github.io/gitment/style/default.css">
<script src="//[username].github.io/gitment/dist/gitment.browser.js"></script>

ALL >>

Hexo Plugin 合集

Hexo Mermaid 插件

官方文档

Step1 Install Package

1
$ yarn add hexo-filter-mermaid-diagrams

In your blog floder, not hexo floder

Step2 Edit Config

After installed, you should edit hexo config file: _config.yml:

1
2
3
4
5
6
# mermaid chart
mermaid: ## mermaid url https://github.com/knsv/mermaid
  enable: true  # default true
  version: "7.1.2" # default v7.1.2
  options:  # find more api options from https://github.com/knsv/mermaid/blob/master/src/mermaidAPI.js
    #startOnload: true  // default true

❗️❗️❗️Notice: if you want to use ‘Class diagram’, please edit your ‘_config.yml’ file, set external_link: false. - hexo bug.

Step3 include mermaid.js in pug or ejs

After edited _config.yml, you shou edit your blog page component like after_footer.pug , after-footer.ejs or swig.

Where is it?

Open your theme folder, you can see the layout folder, open it and then you could see it.

Okey! if your blog is used pug, you can copy the below codes in after_footer.pug:

1
2
3
4
5
6
7
if theme.mermaid.enable == true
  script(type='text/javascript', id='maid-script' mermaidoptioins=theme.mermaid.options src='https://unpkg.com/mermaid@'+ theme.mermaid.version + '/dist/mermaid.min.js' + '?v=' + theme.version)
  script.
    if (window.mermaid) {
      var options = JSON.parse(document.getElementById('maid-script').getAttribute('mermaidoptioins'));
      mermaid.initialize(options);
    }

after-footer.ejs should copy below codes:

1
2
3
4
5
6
7
8
<% if (theme.mermaid.enable) { %>
  <script src='https://unpkg.com/mermaid@<%= theme.mermaid.version %>/dist/mermaid.min.js'></script>
  <script>
    if (window.mermaid) {
      mermaid.initialize({theme: 'forest'});
    }
  </script>
<% } %>

swig template engine:

1
2
3
4
5
6
7
8
{% if theme.mermaid.enable %}
  <script src='https://unpkg.com/mermaid@{{ theme.mermaid.version }}/dist/mermaid.min.js'></script>
  <script>
    if (window.mermaid) {
      mermaid.initialize({{ JSON.stringify(theme.mermaid.options) }});
    }
  </script>
{% endif %}

ALL >>

组件&库 架构方案

最原始方案

所有组件库各自独立维护，独立演进。
搭建私有npm，业务项目独立引用组件库对应版本。

  • 优势

组件之间相互独立，各自互补相干。

  • 劣势

组件库的研发比较麻烦，需要写独立demo。
如果在业务项目中发现组件库出现问题，调试极其麻烦。

  • 适用
    大型团队，组件与业务彻底分离，各自独立演进。

  • 不适用
    小型团队使用成本极大，业务产出低。

ALL >>

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

嗯？ 嗯～