Group items tagged

use all rules keywords, like if, changes, and exists, in the same rule. The rule evaluates to true only when all included keywords evaluate to true.

use parentheses with && and || to build more complicated variable expressions.

Use workflow to specify which types of pipelines can run.

every push to an open merge request’s source branch causes duplicated pipelines.

avoid duplicate pipelines by changing the job rules to avoid either push (branch) pipelines or merge request pipelines.

For behavior similar to the only/except keywords, you can check the value of the $CI_PIPELINE_SOURCE variable

commonly used variables for if clauses

rules:changes expressions to determine when to add jobs to a pipeline

Use !reference tags to reuse rules in different jobs.

Use except to define when a job does not run.

only or except used without refs is the same as only:refs / except/refs

If you change multiple files, but only one file ends in .md, the build job is still skipped.

If you use multiple keywords with only or except, the keywords are evaluated as a single conjoined expression.

only includes the job if all of the keys have at least one condition that matches.

except excludes the job if any of the keys have at least one condition that matches.

To specify a job as manual, add when: manual to the job in the .gitlab-ci.yml file.

Use protected environments to define a list of users authorized to run a manual job.

Use when: delayed to execute scripts after a waiting period, or if you want to avoid jobs immediately entering the pending state.

To split a large job into multiple smaller jobs that run in parallel, use the parallel keyword

run a trigger job multiple times in parallel in a single pipeline, but with different variable values for each instance of the job.

The @ symbol denotes the beginning of a ref’s repository path. To match a ref name that contains the @ character in a regular expression, you must use the hex character code match \x40.

Compare a variable to a string

Check if a variable is undefined

Check if a variable is empty

Check if a variable exists

Check if a variable is empty

Matches are found when using =~.

Matches are not found when using !~.

Join variable expressions together with && or ||

by default they react to !commands in your chatroom. Commands can also trigger on regular expression matches, with or without a bot prefix.

Errbot also supports Markdown responses with Jinja2 templating.

Errbot supports webhooks; It has a small web server that can translate endpoints to your custom plugins.

It’s recommended that you configure this behind a web server such as nginx or Apache.

It works with the If This Then That (IFTTT) principle, meaning that you define a set of rules that the system then uses to take action.

Lita is a chat bot written in Ruby. Like the other bots I’ve mentioned, it is also open source and supports different chat platforms via plugins.

Gort is a newer entrant to the ChatOps space. As the name suggests it has been written in Go, and it is still under active development.

can persist information in databases, supports advanced parsers, and is extendable with custom skills.

軟體是達到目標的手段，而不是目標本身。目標是定向的，但手段要可隨時變通。

不需要維護的程式

10 倍工程師是愚蠢神話。有人能在 1 天內完成另一個有能力、努力工作、有類似經驗的工程師在 2 週內完成的工作，這種想法很愚蠢。

。一個人能夠成為 10 倍工程師的唯一方法，是你把他們和 0.1x 的工程師相比。

between a senior engineer and a junior engineer is that they’ve formed opinions about the way things should be

沒有什麼比一個對自己的工具或如何建構軟體沒有意見的資深工程師更讓我擔心了。

如果你正在使用你的工具，而你對它們不愛也不恨，那麼你需要去體驗更多。

你的資料可能會比你的程式長壽。花點精力保持秩序和乾淨

軟體工程師應該定期撰寫部落格、日記、文件，總之做任何需要他們保持書面溝通能力之事。

如果你把一個人從他們的工作成果中抽離，他們就會對他們的工作不那麼關心。這也是跨職能團隊運作良好的主要原因，也是 DevOps 變得如此流行的原因。從頭到尾擁有整個過程，並直接負責交付價值。讓一群充滿熱情的人對設計、建構和交付一個軟體 (或任何東西) 擁有完全的自主，這終將發生令人驚奇之事。

面試最好是用來瞭解某人是誰，以及他們對某一專業領域的興趣如何。嘗試找出他們會成為多好的團隊成員是一個沒有結果的努力。

你在建構一個系統的過程中會學到很多東西，你最終會迭代成一個比你當初設計的更好的系統。

stop sharpening the saw, and just start cutting shit

mark all jobs as interruptible as it doesn’t make sense to wait for builds and tests based on old information.

only running it when specific files have changed

To prevent the ‘vendor’ and ‘node_modules’ folder from being regenerated in every job, we can configure a build job for composer and npm assets.

To share assets between multiple stages, Gitlab has caches and artifacts. For dependencies we should use caches.

The pull-push policy is the default, but specified here for clarity.

All consecutive runs for the build step with the same ‘composer.lock’ file don’t update the cache.

composer prevents this by caching packages in a global package cache,