Skip to content

Conversation

@ambushwork
Copy link
Member

What does this PR do?

A brief description of the change being made with this pull request.

Motivation

What inspired you to submit this pull request?

Additional Notes

Anything else we should know when reviewing?

Review checklist (to be filled by reviewers)

  • Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
  • Make sure you discussed the feature or bugfix with the maintaining team in an Issue
  • Make sure each commit and the PR mention the Issue number (cf the CONTRIBUTING doc)

@ambushwork ambushwork force-pushed the yl/add-vaults-secrets-defs branch 7 times, most recently from 5e9a81e to 5bde49e Compare November 3, 2025 20:32
@datadog-datadog-prod-us1
Copy link

datadog-datadog-prod-us1 bot commented Nov 3, 2025

🎯 Code Coverage
Patch Coverage: 100.00%
Total Coverage: 70.80% (-0.45%)

View detailed report

This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 85c6bfd | Docs | Datadog PR Page | Was this helpful? Give us feedback!

@codecov-commenter
Copy link

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 70.84%. Comparing base (ee38a9a) to head (5bde49e).
⚠️ Report is 7 commits behind head on develop.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #2974      +/-   ##
===========================================
- Coverage    70.91%   70.84%   -0.07%     
===========================================
  Files          829      829              
  Lines        30381    30381              
  Branches      5184     5184              
===========================================
- Hits         21543    21523      -20     
- Misses        7373     7378       +5     
- Partials      1465     1480      +15     

see 29 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@ambushwork ambushwork force-pushed the yl/add-vaults-secrets-defs branch 17 times, most recently from c83a82e to b166c1b Compare November 10, 2025 15:03
@ambushwork ambushwork force-pushed the yl/add-vaults-secrets-defs branch 2 times, most recently from c096dd5 to bc86c66 Compare November 13, 2025 15:44
@ambushwork ambushwork force-pushed the yl/add-vaults-secrets-defs branch from bc86c66 to 85c6bfd Compare November 18, 2025 09:41
@ambushwork ambushwork changed the title Migrate secrets from aws ssm to vault RUM-11897: Add scripts to set/get Vault secrets & Migrate CI Nov 18, 2025
@ambushwork ambushwork marked this pull request as ready for review November 18, 2025 09:42
@ambushwork ambushwork requested review from a team as code owners November 18, 2025 09:42

fetch-secrets:
stage: fetch-secrets
tags: ["macos:sonoma","specific:true"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a benefit of using macOS runner for that?

Also if it indeed should be macOS runner, then image directive below has no effect.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an obligation, only MacOS runner has the correct IAM role to access Vault of our project.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

only MacOS runner has the correct IAM role

Why so? AFAIK every repo has a unique service account associated, so maybe we can list it as well as account which can have this role?

The fleet of macOS runners is much limited in size, while k8s runners are faster to get and run.

Not a blocker though.

Comment on lines +62 to +66
artifacts:
paths:
- ./ci/pipelines/secrets/
expire_in: 1 hour
when: always
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it a safe thing to have? it means that anyone with just a basic Gitlab CI access can download this, not only RUM team members.

Moreover, it makes this artifact available for 1 hour, meaning it is still there even after pipeline completed, failed.

Should we maybe fetch secrets only in the boundaries of the particular job?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

since the default behavior will be only uploading artifacts when success, do you think remove when:always will improve this?
fetching secrets in each job may cause repeat vault login and vault get, it may increase the CI time, I can ask around if this is a safe way

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fetching secrets in each job may cause repeat vault login and vault get

It should be fast. Anyway, by constraining secrets lifetime only to the particular job and removing the possibility to fetch them as an artifact we limit access only to the Repo Admins/Contributors (it is still possible to modify CI script to read them) compared to the Job artifacts access which is possible for everyone with dev access.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants