Test weekly reset

[avidal]

No description provided.

[datadog-datadog-prod-us1]

✅ Libraries

ℹ️ Info

🎉 All green!

📚 No new vulnerable libraries detected

This comment will be updated automatically if new data arrives.

_{🔗 Commit SHA: 52c78c0 | Was this helpful? Give us feedback!}

[avidal]

Okay. It works.

You can see the changes I made to the reset script (sourced from dogweb) and the "bootstrap" script (sourced from web-ui, but each repository that uses it has their own similar version) by looking at this commit which excludes the initial commit.

It leverages this dd-octo-sts policy to get a token to manipulate the repository. It also uses this token in the bootstrap to fetch the actual script, but that's a special case.

If you look at recent commits on reset-base you can see the commits created by the script that are updating CURRENT_STAGING.

Additionally, you can see the in the "old" staging branch staging-30a that the follow-up commit to delete .gitlab-ci.yml was also successful.

What's left?

• An org-scoped dd-octo-sts policy allowing contents:read for dogweb from pipelines within the source repositories (dogweb, logs-backend, profiling-backend, web-ui)
• A repo-scoped policy similar to the one in this repository in each actual source repository
• An update to staging-reset.sh in dogweb that reflects the changes in this PR (in .ci/staging-reset-source.sh)
• An update to each source repository so that they use something similar to .ci/reset-staging.sh to fetch tokens from dd-octo-sts, and so that they run the job in an image that has dd-octo-sts and commit-headless binaries

For compatibility reasons, I suggest the staging-reset.sh changes in dogweb are either a new name or on a branch so that source repository bootstrap scripts can "opt-in" to downloading the new version.

[avidal]

One interesting thing I noticed in my tests is that the reset script, when it attempts to approve its own PR, is this error from GitHub:

{
  "message": "Unprocessable Entity",
  "errors": [
    "Can not approve your own pull request"
  ],
  "documentation_url": "https://docs.github.com/rest/pulls/reviews#create-a-review-for-a-pull-request",
  "status": "422"
}

The original script used two different tokens, a "normal" token that creates and merges the PR, and an "admin" token that approves it. If we look at an automated pull request in web-ui you can see that the "normal" token is Dwight Tilghman ([email protected]) and the "admin" token is datadog-build-engineering-robot.

Because all of the tokens in-use here are coming from dd-octo-sts there is no way to have two users, so there may be an issue if the repository requires a separate review from someone with write access.

[avidal]

Alright. I addressed the reviewer issue with a simple action workflow.

It is designed to automatically approve any pull request where the source branch starts with staging-reset/staging- and targeting the "base branch" (which in my test case is reset-base, same as what the job uses).

Additionally, I removed the approval step from the actual staging-reset.sh script.

You can see the PR here: #25

[avidal]

For anyone watching here, using the Action to auto-approve is a no go, as it requires setting the unsafe repository setting that allows actions to approve and create pull requests.

We're trying to get access to the user account used (currently) to approve & merge, at which point we'll get a fine grained token and use that (replacing only the token used to commit with dd-octo-sts).