GitLab의 핵심은 Ruby on Rails 프레임워크를 사용하여 구축된 웹 애플리케이션입니다. Rails 콘솔은 명령줄에서 GitLab 인스턴스와 상호 작용하는 방법을 제공하며, Rails에 내장된 놀라운 도구들에 대한 액세스도 부여합니다.

Rails 콘솔은 문제를 트러블슈팅하거나 GitLab 애플리케이션에 대한 직접 액세스를 통해서만 가져올 수 있는 데이터가 필요한 GitLab 시스템 관리자를 위한 것입니다. Ruby에 대한 기본 지식이 필요합니다(빠른 소개를 위해 이 30분 튜토리얼을 시도해 보세요). Rails 경험은 유용하지만 필수는 아닙니다.

Rails 콘솔 세션 시작#

Rails 콘솔 세션을 시작하는 프로세스는 GitLab 설치 유형에 따라 다릅니다.

sudo gitlab-rails console

docker exec -it <container-id> gitlab-rails console

sudo -u git -H bundle exec rails console -e production

# find the pod
kubectl get pods --namespace <namespace> -lapp=toolbox

# open the Rails console
kubectl exec -it -c toolbox <toolbox-pod-name> -- gitlab-rails console

콘솔을 종료하려면 quit를 입력합니다.

자동 완성 비활성화#

Ruby 자동 완성은 터미널 속도를 느리게 할 수 있습니다. 원하는 경우:

• 자동 완성을 비활성화하려면 Reline.autocompletion = IRB.conf[:USE_AUTOCOMPLETE] = false를 실행합니다.
• 자동 완성을 다시 활성화하려면 Reline.autocompletion = IRB.conf[:USE_AUTOCOMPLETE] = true를 실행합니다.

Active Record 로깅 활성화#

Rails 콘솔 세션에서 Active Record 디버그 로깅 출력을 활성화하려면 다음을 실행합니다:

ActiveRecord::Base.logger = Logger.new($stdout)

기본적으로 이전 스크립트는 표준 출력에 로그를 기록합니다. $stdout을 원하는 파일 경로로 바꿔 출력을 리디렉션할 로그 파일을 지정할 수 있습니다. 예를 들어, 이 코드는 모든 것을 /tmp/output.log에 기록합니다:

ActiveRecord::Base.logger = Logger.new('/tmp/output.log')

이것은 콘솔에서 실행하는 Ruby 코드에 의해 트리거된 데이터베이스 쿼리에 대한 정보를 보여줍니다. 로깅을 다시 끄려면 다음을 실행합니다:

ActiveRecord::Base.logger = nil

속성#

pretty print(pp)를 사용하여 사용 가능한 속성을 보기 좋게 출력합니다.

예를 들어, 사용자 이름과 이메일 주소를 포함하는 속성을 확인합니다:

u = User.find_by_username('someuser')
pp u.attributes

부분 출력:

{"id"=>1234,
 "email"=>"someuser@example.com",
 "sign_in_count"=>99,
 "name"=>"S User",
 "username"=>"someuser",
 "first_name"=>nil,
 "last_name"=>nil,
 "bot_type"=>nil}

그런 다음 SMTP 테스트와 같은 속성을 활용합니다:

e = u.email
n = u.name
Notify.test_email(e, "Test email for #{n}", 'Test email').deliver_now
#
Notify.test_email(u.email, "Test email for #{u.name}", 'Test email').deliver_now

데이터베이스 명령문 타임아웃 비활성화#

현재 Rails 콘솔 세션에 대한 PostgreSQL 명령문 타임아웃을 비활성화할 수 있습니다.

GitLab 15.11 이하에서 데이터베이스 명령문 타임아웃을 비활성화하려면 다음을 실행합니다:

ActiveRecord::Base.connection.execute('SET statement_timeout TO 0')

GitLab 16.0 이상에서는 GitLab이 기본적으로 두 개의 데이터베이스 연결을 사용합니다. 데이터베이스 명령문 타임아웃을 비활성화하려면 다음을 실행합니다:

ActiveRecord::Base.connection.execute('SET statement_timeout TO 0')
Ci::ApplicationRecord.connection.execute('SET statement_timeout TO 0')

단일 데이터베이스 연결을 사용하도록 재구성된 GitLab 16.0 이상의 인스턴스는 GitLab 15.11 이하의 코드를 사용하여 데이터베이스 명령문 타임아웃을 비활성화해야 합니다.

데이터베이스 명령문 타임아웃 비활성화는 현재 Rails 콘솔 세션에만 영향을 미치며 GitLab 프로덕션 환경이나 다음 Rails 콘솔 세션에는 유지되지 않습니다.

Rails 콘솔 세션 히스토리 출력#

Rails 콘솔에서 다음 명령을 입력하여 명령 히스토리를 표시합니다.

puts Reline::HISTORY.to_a

그런 다음 클립보드에 복사하여 나중에 참조하기 위해 저장할 수 있습니다.

Rails Runner 사용#

GitLab 프로덕션 환경의 컨텍스트에서 일부 Ruby 코드를 실행해야 하는 경우 Rails Runner를 사용하여 수행할 수 있습니다. 스크립트 파일을 실행할 때 스크립트는 git 사용자가 액세스할 수 있어야 합니다.

명령이나 스크립트가 완료되면 Rails Runner 프로세스가 종료됩니다. 다른 스크립트나 cron 작업 등에서 실행하는 데 유용합니다.

• Linux 패키지 설치의 경우:

  sudo gitlab-rails runner "RAILS_COMMAND"
  
  # Example with a two-line Ruby script
  sudo gitlab-rails runner "user = User.first; puts user.username"
  
  # Example with a ruby script file (make sure to use the full path)
  sudo gitlab-rails runner /path/to/script.rb
  

• 자체 컴파일 설치의 경우:

  sudo -u git -H bundle exec rails runner -e production "RAILS_COMMAND"
  
  # Example with a two-line Ruby script
  sudo -u git -H bundle exec rails runner -e production "user = User.first; puts user.username"
  
  # Example with a ruby script file (make sure to use the full path)
  sudo -u git -H bundle exec rails runner -e production /path/to/script.rb
  

Rails Runner는 콘솔과 같은 출력을 생성하지 않습니다.

콘솔에서 변수를 설정하면 콘솔은 변수 내용이나 참조된 엔터티의 속성과 같은 유용한 디버그 출력을 생성합니다:

irb(main):001:0> user = User.first
=> #

Rails Runner는 이를 수행하지 않으므로 출력을 명시적으로 생성해야 합니다:

$ sudo gitlab-rails runner "user = User.first"
$ sudo gitlab-rails runner "user = User.first; puts user.username ; puts user.id"
root
1

Ruby에 대한 기본 지식이 매우 유용합니다. 빠른 소개를 위해 이 30분 튜토리얼을 시도해 보세요. Rails 경험은 도움이 되지만 필수는 아닙니다.

객체의 특정 메서드 찾기#

Array.methods.select { |m| m.to_s.include? "sing" }
Array.methods.grep(/sing/)

메서드 소스 찾기#

instance_of_object.method(:foo).source_location

# Example for when we would call project.private?
project.method(:private?).source_location

출력 제한#

명령문 끝에 세미콜론(;)과 후속 명령문을 추가하면 기본 암시적 반환 출력이 방지됩니다. 이미 명시적으로 세부 정보를 출력하고 있고 반환 출력이 많을 경우에 사용할 수 있습니다:

puts ActiveRecord::Base.descendants; :ok
Project.select(&:pages_deployed?).each {|p| puts p.path }; true

마지막 작업의 결과 가져오기 또는 저장#

밑줄(_)은 이전 명령문의 암시적 반환을 나타냅니다. 이를 사용하여 이전 명령의 출력에서 변수를 빠르게 할당할 수 있습니다:

Project.last
# => #>
project = _
# => #>
project.id
# => 2537

작업 시간 측정#

하나 이상의 작업을 시간 측정하려면, 자리 표시자 <operation>을 원하는 Ruby 또는 Rails 명령으로 바꿔 다음 형식을 사용합니다:

# A single operation
Benchmark.measure { <operation> }

# A breakdown of multiple operations
Benchmark.bm do |x|
  x.report(:label1) { <operation_1> }
  x.report(:label2) { <operation_2> }
end

자세한 내용은 벤치마크에 대한 개발자 설명서를 검토하세요.

Active Record 객체#

데이터베이스에 저장된 객체 조회#

내부적으로 Rails는 Active Record를 사용하며, 이는 애플리케이션 객체를 PostgreSQL 데이터베이스에 읽고, 쓰고, 매핑하는 객체 관계형 매핑 시스템입니다. 이러한 매핑은 Rails 앱에 정의된 Ruby 클래스인 Active Record 모델에 의해 처리됩니다. GitLab의 경우 모델 클래스는 /opt/gitlab/embedded/service/gitlab-rails/app/models에서 찾을 수 있습니다.

Active Record에 대한 디버그 로깅을 활성화하여 기반이 되는 데이터베이스 쿼리를 확인해 봅시다:

ActiveRecord::Base.logger = Logger.new($stdout)

이제 데이터베이스에서 사용자를 가져와 봅시다:

user = User.find(1)

반환 결과:

D, [2020-03-05T16:46:25.571238 #910] DEBUG -- :   User Load (1.8ms)  SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
=> #

id 컬럼 값이 1인 행에 대해 데이터베이스의 users 테이블을 쿼리했으며, Active Record는 해당 데이터베이스 레코드를 상호 작용할 수 있는 Ruby 객체로 변환했습니다. 다음을 시도해 보세요:

• user.username
• user.created_at
• user.admin

관례에 따라 컬럼 이름은 Ruby 객체 속성으로 직접 변환되므로, user.<column_name>으로 속성 값을 볼 수 있어야 합니다.

또한 관례에 따라 Active Record 클래스 이름(단수, 카멜 케이스)은 테이블 이름(복수, 스네이크 케이스)으로 직접 매핑되며 반대도 마찬가지입니다. 예를 들어, users 테이블은 User 클래스에 매핑되고, application_settings 테이블은 ApplicationSetting 클래스에 매핑됩니다.

테이블 목록과 컬럼 이름은 Rails 데이터베이스 스키마(``/opt/gitlab/embedded/service/gitlab-rails/db/schema.rb`)에서 찾을 수 있습니다.

속성 이름으로 데이터베이스에서 객체를 조회할 수도 있습니다:

user = User.find_by(username: 'root')

반환 결과:

D, [2020-03-05T17:03:24.696493 #910] DEBUG -- :   User Load (2.1ms)  SELECT "users".* FROM "users" WHERE "users"."username" = 'root' LIMIT 1
=> #

다음을 시도해 보세요:

• User.find_by(username: 'root')
• User.where.not(admin: true)
• User.where('created_at < ?', 7.days.ago)

마지막 두 명령이 여러 User 객체를 포함하는 것처럼 보이는 ActiveRecord::Relation 객체를 반환했다는 것을 알아챘나요?

지금까지 단일 객체만 반환하도록 설계된 .find 또는 .find_by를 사용했습니다(생성된 SQL 쿼리에서 LIMIT 1을 알아챌 수 있나요?). .where는 객체 컬렉션을 가져오고자 할 때 사용됩니다.

비관리자 사용자 컬렉션을 가져와 무엇을 할 수 있는지 살펴봅시다:

users = User.where.not(admin: true)

반환 결과:

D, [2020-03-05T17:11:16.845387 #910] DEBUG -- :   User Load (2.8ms)  SELECT "users".* FROM "users" WHERE "users"."admin" != TRUE LIMIT 11
=> #, #, #, #, #]>

이제 다음을 시도해 보세요:

• users.count
• users.order(created_at: :desc)
• users.where(username: 'support-bot')

마지막 명령에서 .where 명령문을 연결하여 더 복잡한 쿼리를 생성할 수 있다는 것을 알 수 있습니다. 또한 컬렉션이 단일 객체만 포함하고 있어도 직접 상호 작용할 수 없다는 것도 알아챌 수 있습니다:

users.where(username: 'support-bot').username

반환 결과:

Traceback (most recent call last):
        1: from (irb):37
D, [2020-03-05T17:18:25.637607 #910] DEBUG -- :   User Load (1.6ms)  SELECT "users".* FROM "users" WHERE "users"."admin" != TRUE AND "users"."username" = 'support-bot' LIMIT 11
NoMethodError (undefined method `username' for #]>)
Did you mean?  by_username

.first 메서드를 사용하여 컬렉션에서 첫 번째 항목을 가져와 단일 객체를 가져옵시다:

users.where(username: 'support-bot').first.username

이제 원하는 결과를 얻었습니다:

D, [2020-03-05T17:18:30.406047 #910] DEBUG -- :   User Load (2.6ms)  SELECT "users".* FROM "users" WHERE "users"."admin" != TRUE AND "users"."username" = 'support-bot' ORDER BY "users"."id" ASC LIMIT 1
=> "support-bot"

Active Record를 사용하여 데이터베이스에서 데이터를 가져오는 다양한 방법에 대한 자세한 내용은 Active Record 쿼리 인터페이스 설명서를 참조하세요.

Active Record 모델을 사용하여 데이터베이스 쿼리#

m = Model.where('attribute like ?', 'ex%')

# for example to query the projects
projects = Project.where('path like ?', 'Oumua%')

Active Record 객체 수정#

이전 섹션에서 Active Record를 사용하여 데이터베이스 레코드를 가져오는 방법을 배웠습니다. 이제 데이터베이스에 변경 사항을 쓰는 방법을 배워봅시다.

먼저 root 사용자를 가져옵니다:

user = User.find_by(username: 'root')

다음으로 사용자 비밀번호를 업데이트해 봅시다:

user.password = 'password'
user.save

반환 결과:

Enqueued ActionMailer::MailDeliveryJob (Job ID: 05915c4e-c849-4e14-80bb-696d5ae22065) to Sidekiq(mailers) with arguments: "DeviseMailer", "password_change", "deliver_now", #>
=> true

여기서 .save 명령이 true를 반환했는데, 이는 비밀번호 변경이 데이터베이스에 성공적으로 저장되었음을 나타냅니다.

또한 저장 작업이 다른 작업을 트리거했다는 것도 알 수 있습니다. 이 경우 이메일 알림을 전달하는 백그라운드 작업입니다. 이것은 Active Record 콜백의 예입니다. 직접 데이터베이스 쿼리를 통해 변경된 내용은 이러한 콜백을 트리거하지 않으므로, 데이터에 직접 변경이 필요한 경우 Rails 콘솔을 사용하는 것이 선호되는 이유입니다.

단일 줄로 속성을 업데이트하는 것도 가능합니다:

user.update(password: 'password')

또는 한 번에 여러 속성을 업데이트할 수 있습니다:

user.update(password: 'password', email: 'hunter2@example.com')

이제 다른 것을 시도해 봅시다:

# Retrieve the object again so we get its latest state
user = User.find_by(username: 'root')
user.password = 'password'
user.password_confirmation = 'hunter2'
user.save

이것은 false를 반환하는데, 변경 사항이 데이터베이스에 저장되지 않았음을 나타냅니다. 이유를 짐작할 수 있지만 확실히 알아봅시다:

user.save!

반환 결과:

Traceback (most recent call last):
        1: from (irb):64
ActiveRecord::RecordInvalid (Validation failed: Password confirmation doesn't match Password)

Active Record 유효성 검사에 걸렸습니다! 유효성 검사는 애플리케이션 레벨에서 원하지 않는 데이터가 데이터베이스에 저장되는 것을 방지하기 위해 설정된 비즈니스 로직으로, 대부분의 경우 문제 입력을 수정하는 방법을 알려주는 유용한 메시지와 함께 제공됩니다.

.update에도 느낌표(Ruby에서 !)를 추가할 수 있습니다:

user.update!(password: 'password', password_confirmation: 'hunter2')

Ruby에서 !로 끝나는 메서드 이름은 일반적으로 "뱅 메서드(bang methods)"로 알려져 있습니다. 관례에 따라 뱅은 메서드가 변환된 결과를 반환하고 기반 객체를 변경하지 않는 대신, 작동 중인 객체를 직접 수정한다는 것을 나타냅니다. 데이터베이스에 쓰는 Active Record 메서드의 경우 뱅 메서드는 추가 기능도 제공합니다. false를 반환하는 대신 오류가 발생하면 명시적 예외를 발생시킵니다.

유효성 검사를 완전히 건너뛸 수도 있습니다:

# Retrieve the object again so we get its latest state
user = User.find_by(username: 'root')
user.password = 'password'
user.password_confirmation = 'hunter2'
user.save!(validate: false)

유효성 검사는 일반적으로 사용자 제공 데이터의 무결성과 일관성을 보장하기 위해 마련되므로 이 방법은 권장되지 않습니다.

유효성 검사 오류는 전체 객체가 데이터베이스에 저장되는 것을 방지합니다. 아래 섹션에서 이것을 조금 더 살펴볼 수 있습니다. GitLab UI에서 양식 제출 시 이유를 알 수 없는 빨간 배너가 표시된다면, 이것이 종종 문제의 근본 원인을 파악하는 가장 빠른 방법일 수 있습니다.

Active Record 객체와 상호 작용#

결국 Active Record 객체는 표준 Ruby 객체에 불과합니다. 따라서 임의의 동작을 수행하는 메서드를 정의할 수 있습니다.

예를 들어, GitLab 개발자들이 이중 인증을 지원하는 일부 메서드를 추가했습니다:

def disable_two_factor!
  transaction do
    update(
      otp_required_for_login:      false,
      encrypted_otp_secret:        nil,
      encrypted_otp_secret_iv:     nil,
      encrypted_otp_secret_salt:   nil,
      otp_grace_period_started_at: nil,
      otp_backup_codes:            nil
    )
    self.second_factor_webauthn_registrations.destroy_all # rubocop: disable DestroyAll
  end
end

def two_factor_enabled?
  two_factor_otp_enabled? || two_factor_webauthn_enabled?
end

(참조: /opt/gitlab/embedded/service/gitlab-rails/app/models/user.rb)

그런 다음 모든 사용자 객체에서 이러한 메서드를 사용할 수 있습니다:

user = User.find_by(username: 'root')
user.two_factor_enabled?
user.disable_two_factor!

일부 메서드는 GitLab이 사용하는 Ruby 소프트웨어 패키지인 gem으로 정의됩니다. 예를 들어, GitLab이 사용자 상태를 관리하기 위해 사용하는 StateMachines gem:

state_machine :state, initial: :active do
  event :block do

  ...

  event :activate do

  ...

end

시도해 보세요:

user = User.find_by(username: 'root')
user.state
user.block
user.state
user.activate
user.state

앞서 유효성 검사 오류가 전체 객체를 데이터베이스에 저장하는 것을 방지한다고 언급했습니다. 이것이 예기치 않은 상호 작용을 어떻게 일으킬 수 있는지 살펴봅시다:

user.password = 'password'
user.password_confirmation = 'hunter2'
user.block

false가 반환됩니다! 앞서 했던 것처럼 뱅을 추가하여 무슨 일이 일어났는지 알아봅시다:

user.block!

반환 결과:

Traceback (most recent call last):
        1: from (irb):87
StateMachines::InvalidTransition (Cannot transition state via :block from :active (Reason(s): Password confirmation doesn't match Password))

완전히 별개의 속성에서 발생한 유효성 검사 오류가 사용자를 어떤 방식으로든 업데이트하려 할 때 다시 나타납니다.

실제로 GitLab 관리 설정에서 이러한 상황이 발생하는 것을 봅니다. GitLab 업데이트 시 유효성 검사가 추가되거나 변경되어 이전에 저장된 설정이 이제 유효성 검사에 실패하는 경우가 있습니다. UI를 통해 한 번에 일부 설정만 업데이트할 수 있으므로, 이 경우 좋은 상태로 돌아가는 유일한 방법은 Rails 콘솔을 통한 직접 조작입니다.

일반적으로 사용되는 Active Record 모델과 객체 조회 방법#

기본 이메일 주소 또는 사용자 이름으로 사용자 가져오기:

User.find_by(email: 'admin@example.com')
User.find_by(username: 'root')

기본 또는 보조 이메일 주소로 사용자 가져오기:

User.find_by_any_email('user@example.com')

find_by_any_email 메서드는 Rails가 제공하는 기본 메서드가 아닌 GitLab 개발자들이 추가한 사용자 정의 메서드입니다.

관리자 사용자 컬렉션 가져오기:

User.admins

admins는 내부적으로 where(admin: true)를 수행하는 스코프 편의 메서드입니다.

경로로 프로젝트 가져오기:

Project.find_by_full_path('group/subgroup/project')

find_by_full_path는 Rails가 제공하는 기본 메서드가 아닌 GitLab 개발자들이 추가한 사용자 정의 메서드입니다.

숫자 ID로 프로젝트의 이슈 또는 머지 리퀘스트 가져오기:

project = Project.find_by_full_path('group/subgroup/project')
project.issues.find_by(iid: 42)
project.merge_requests.find_by(iid: 42)

iid는 "내부 ID"를 의미하며 이슈 및 머지 리퀘스트 ID를 각 GitLab 프로젝트로 범위를 지정하는 방법입니다.

경로로 그룹 가져오기:

Group.find_by_full_path('group/subgroup')

그룹의 관련 그룹 가져오기:

group = Group.find_by_full_path('group/subgroup')

# Get a group's parent group
group.parent

# Get a group's child groups
group.children

그룹의 프로젝트 가져오기:

group = Group.find_by_full_path('group/subgroup')

# Get group's immediate child projects
group.projects

# Get group's child projects, including those in subgroups
group.all_projects

CI 파이프라인 또는 빌드 가져오기:

Ci::Pipeline.find(4151)
Ci::Build.find(66124)

파이프라인 및 작업 ID 번호는 GitLab 인스턴스 전체에서 전역적으로 증가하므로, 이슈나 머지 리퀘스트와 달리 조회에 내부 ID 속성을 사용할 필요가 없습니다.

현재 애플리케이션 설정 객체 가져오기:

ApplicationSetting.current

irb에서 객체 열기#

메서드를 탐색할 때 객체의 컨텍스트에 있으면 더 쉬울 때가 있습니다. Object의 네임스페이스에 shim을 추가하여 모든 객체의 컨텍스트에서 irb를 열 수 있습니다:

Object.define_method(:irb) { binding.irb }

project = Project.last
# => #>
project.irb
# Notice new context
irb(#)> web_url
# => "https://gitlab-example/root/discard"

트러블슈팅#

Rails Runner syntax error#

gitlab-rails 명령은 기본적으로 비루트 계정과 그룹(git:git)을 사용하여 Rails Runner를 실행합니다.

비루트 계정이 gitlab-rails runner에 전달된 Ruby 스크립트 파일명을 찾을 수 없는 경우 파일에 액세스할 수 없다는 오류가 아닌 구문 오류가 발생할 수 있습니다.

일반적인 이유는 스크립트가 루트 계정의 홈 디렉터리에 저장된 경우입니다.

runner는 경로 및 파일 매개변수를 Ruby 코드로 파싱하려고 합니다.

예를 들어:

[root ~]# echo 'puts "hello world"' > ./helloworld.rb
[root ~]# sudo gitlab-rails runner ./helloworld.rb
Please specify a valid ruby command or the path of a script to run.
Run 'rails runner -h' for help.

/opt/gitlab/..../runner_command.rb:45: syntax error, unexpected '.'
./helloworld.rb
^
[root ~]# sudo gitlab-rails runner /root/helloworld.rb
Please specify a valid ruby command or the path of a script to run.
Run 'rails runner -h' for help.

/opt/gitlab/..../runner_command.rb:45: unknown regexp options - hllwrld
[root ~]# mv ~/helloworld.rb /tmp
[root ~]# sudo gitlab-rails runner /tmp/helloworld.rb
hello world

디렉터리는 액세스할 수 있지만 파일에 액세스할 수 없는 경우 의미 있는 오류가 생성되어야 합니다:

[root ~]# chmod 400 /tmp/helloworld.rb
[root ~]# sudo gitlab-rails runner /tmp/helloworld.rb
Traceback (most recent call last):
      [traceback removed]
/opt/gitlab/..../runner_command.rb:42:in `load': cannot load such file -- /tmp/helloworld.rb (LoadError)

다음과 같은 유사한 오류가 발생하는 경우:

[root ~]# sudo gitlab-rails runner helloworld.rb
Please specify a valid ruby command or the path of a script to run.
Run 'rails runner -h' for help.

undefined local variable or method `helloworld' for main:Object

파일을 /tmp 디렉터리로 이동하거나 아래와 같이 git 사용자가 소유한 새 디렉터리를 만들고 해당 디렉터리에 스크립트를 저장할 수 있습니다:

sudo mkdir /scripts
sudo mv /script_path/helloworld.rb /scripts
sudo chown -R git:git /scripts
sudo chmod 700 /scripts
sudo gitlab-rails runner /scripts/helloworld.rb

필터링된 콘솔 출력#

콘솔의 일부 출력은 변수, 로그 또는 비밀과 같은 특정 값의 유출을 방지하기 위해 기본적으로 필터링될 수 있습니다. 이 출력은 [FILTERED]로 표시됩니다. 예를 들어:

> Plan.default.actual_limits
=> ci_instance_level_variables: "[FILTERED]",

필터링을 우회하려면 객체에서 직접 값을 읽습니다. 예를 들어:

> Plan.default.limits.ci_instance_level_variables
=> 25