[WIP] feat: DB ESDK Python

[imabhichow]

Issue #, if available:

Description of changes:

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

To fix this problem, we should specify a permissions block at the top level of the workflow file (just after the name: and before on:), or at least at the job level for each job. The simplest and safest way to ensure least privilege is to add to the workflow-level a permissions block granting only contents: read, which suffices for the majority of jobs that only need to access code, not modify it or update PRs. If any jobs require additional permissions (e.g., to create issues, post comments, or write to contents), these can be granted on a per-job basis. In this case, there is no evidence from the provided snippet that any jobs need more than contents: read.
To implement this, add the following block to .github/workflows/daily_ci.yml immediately after name: Daily CI at line 3:

permissions:
  contents: read

No additional imports, methods, or definitions are needed for this change.

The best way to fix this problem is to specify a top-level permissions block at the root of the workflow, immediately below the name: or on: key. This will apply to all jobs in the workflow that do not have their own explicit permissions setting, thereby applying the principle of least privilege. Since most CI workflows do not need write access, setting contents: read provides the minimal permissions required for most build and test operations, and can be relaxed for individual jobs if necessary. The change is to add:

permissions:
  contents: read

directly after the name: Daily CI line in the .github/workflows/daily_ci.yml file.

The best way to fix this problem is to explicitly set a permissions: block near the top of the workflow file (at the root level, above jobs:). This will apply to all jobs unless any override permissions at the job level. The safest, least-privilege default for most CI workflows is permissions: { contents: read }, which allows jobs to clone and read repository contents but not to write or change anything, nor to create or manage issues, pull requests, etc.

You should edit the workflow .github/workflows/daily_ci.yml and insert the following lines after the workflow name: block and before on::

permissions:
  contents: read

No additional setup or definitions are needed.

---

The best way to fix this problem is to add a permissions block at the top of the workflow YAML file (just after the name: or on: fields). This block should specify the minimal GITHUB_TOKEN permissions required for the workflow to function. Since this workflow orchestrates other workflows and does not itself perform any repository write operations, contents: read (the most basic permission for accessing repository contents) is usually sufficient. If one of the called jobs needs more, it can override via its own permissions block. This fix involves editing .github/workflows/manual.yml to add the following block near the top:

permissions:
  contents: read

No changes to imports, method definitions, or additional dependencies are required.

---

To fix the problem, you should add a permissions block at the root of the workflow (just below name: and above on:) in .github/workflows/manual.yml. This block sets the default permissions for all jobs in this workflow that do not have their own explicit permissions block, reducing unnecessary rights for the GITHUB_TOKEN. To follow "least privilege", start with contents: read (the minimal required for most CI tasks), and add write scopes only for those resource types where required (e.g., pull-requests: write if the workflow needs to update or comment on PRs). In absence of more detailed needs (which are not given here), a safe default is:

permissions:
  contents: read

Place this just before the on: key to apply it globally to the workflow.

To fix this problem, explicitly define the permissions: block at the root level of the workflow file (i.e., at the top, right after the name: and before on:). The permissions should be set to the minimum necessary. If no jobs in this workflow (or in the reusable workflows it calls) require write access (such as for creating/status checks, updating pull requests, etc.), set contents: read as a safe minimum. If any jobs require additional permissions, they can be added to the root or specified individually at the job level. Based on the file shown, a minimal default would be:

permissions:
  contents: read

Insert this block after the name: line (line 2), shifting all subsequent lines down by one.

---

To remediate this issue, you should add a permissions block to the top level of the workflow YAML file. This block specifies the minimum GitHub token permissions all jobs inherit, unless overridden. The most restrictive safe default for CI typically is:

permissions:
  contents: read

If any individual job requires greater permissions (such as for commenting on pull requests), you can override (broaden) permissions on a per-job basis.
In this code, prepend the workflow file with the recommended permissions block as close to the top as possible, ideally directly after the name: and before on:. This process does not alter the logic or output of the existing workflow, only constrains the implicit permissions available to jobs.

To address this issue, set an explicit permissions block at the top (root) level of the workflow. This permissions block should grant only the minimum required scope for all jobs in this workflow. In most CI workflows, contents: read is the safest possible permission unless something in a job/pipeline needs to write to issues, pull requests, etc. Since this workflow primarily calls reusable workflows and we have not been shown any evidence that those require write privileges, use permissions: contents: read at the root level (just after the name: block and before on:). If future changes require additional permissions, they can be granted at the job or step level as needed.

Edit .github/workflows/push.yml:

• Add the line permissions:\n contents: read after the name: Push CI at the top of the workflow, before on: (i.e., between lines 2 and 3).
• No other changes are required.

---

To fix the problem, add a permissions: block at the root level of the workflow (push.yml). This block will apply to all jobs within the workflow unless overridden in individual jobs or inside each called reusable workflow. The best way is to set the minimal permissions required: typically, contents: read suffices unless the jobs require write access (for example, for creating pull requests or issues). Since this dispatcher workflow appears to coordinate CI processes rather than make repository changes, contents: read is likely sufficient. Insert the following immediately after the name: Push CI (line 2), before the on: event block.

To fix the problem, we should explicitly declare a permissions key in the workflow YAML. This can be placed either at the very top (root level, affecting all jobs by default) or per job. Since all jobs seem to follow the same pattern and do not appear to need write access, placing permissions: contents: read at the root of the workflow (under name and before jobs) will apply the minimum permissions to all jobs, adhering to the principle of least privilege. There are no external definitions, methods, or imports needed, only a single YAML key addition.

---