ci: setup building nuget packages in CI #697
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,102 @@ | ||
| on: | ||
| push: | ||
| branches: | ||
| - main | ||
| pull_request: | ||
|
|
||
| name: .NET | ||
|
|
||
| jobs: | ||
| windows-build: | ||
| runs-on: windows-latest | ||
| steps: | ||
| - name: checkout | ||
| uses: actions/checkout@v4 | ||
|
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
|
||
|
|
||
| - name: Install rustup using win.rustup.rs | ||
| run: | | ||
| # disable download progress bar | ||
| $ProgressPreference = "SilentlyContinue" | ||
| Invoke-WebRequest https://win.rustup.rs/ -OutFile rustup-init.exe | ||
| .\rustup-init.exe -y --default-host=x86_64-pc-windows-msvc --default-toolchain=none | ||
| del rustup-init.exe | ||
| rustup target add x86_64-pc-windows-msvc | ||
| rustup target add i686-pc-windows-msvc | ||
| shell: powershell | ||
|
|
||
| - name: build | ||
| run: | | ||
| .\windows\build\build.ps1 -output_dir .\bin | ||
|
|
||
| - name: Upload artifacts | ||
| uses: actions/upload-artifact@v4 | ||
|
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
|
||
| with: | ||
| name: windows-bin | ||
| path: | | ||
| bin/x86_64-pc-windows-msvc/*/datadog_profiling_ffi.dll | ||
| bin/x86_64-pc-windows-msvc/*/datadog_profiling_ffi.lib | ||
| bin/x86_64-pc-windows-msvc/*/datadog_profiling_ffi.pdb | ||
| bin/i686-pc-windows-msvc/*/datadog_profiling_ffi.dll | ||
| bin/i686-pc-windows-msvc/*/datadog_profiling_ffi.lib | ||
| bin/i686-pc-windows-msvc/*/datadog_profiling_ffi.pdb | ||
| if-no-files-found: error | ||
|
|
||
| macos-build: | ||
| runs-on: macos-latest | ||
| steps: | ||
| - name: checkout | ||
| uses: actions/checkout@v4 | ||
|
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
|
||
|
|
||
| - name: Install rustup using rustup.rs | ||
| run: | | ||
| curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y | ||
| source $HOME/.cargo/env | ||
| rustup target add x86_64-apple-darwin | ||
| rustup target add aarch64-apple-darwin | ||
| shell: bash | ||
|
|
||
| - name: build | ||
| run: | | ||
| chmod +x ./windows/build/build.sh | ||
| ./windows/build/build.sh -o ./bin | ||
|
|
||
| - name: Upload artifacts | ||
| uses: actions/upload-artifact@v4 | ||
|
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
|
||
| with: | ||
| name: macos-bin | ||
| path: | | ||
| bin/x86_64-apple-darwin/*/libdatadog_profiling_ffi.dylib | ||
| bin/x86_64-apple-darwin/*/libdatadog_profiling_ffi.a | ||
| bin/aarch64-apple-darwin/*/libdatadog_profiling_ffi.dylib | ||
| bin/aarch64-apple-darwin/*/libdatadog_profiling_ffi.a | ||
| if-no-files-found: error | ||
|
|
||
| pack: | ||
| runs-on: windows-latest | ||
| needs: [windows-build, macos-build] | ||
| steps: | ||
| - name: checkout | ||
| uses: actions/checkout@v4 | ||
|
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
|
||
|
|
||
| - name: Download Windows artifacts | ||
| uses: actions/download-artifact@v4 | ||
|
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
|
||
| with: | ||
| name: windows-bin | ||
| path: bin | ||
|
|
||
| - name: Download mac artifacts | ||
| uses: actions/download-artifact@v4 | ||
|
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
|
||
| with: | ||
| name: macos-bin | ||
| path: bin | ||
|
|
||
| - name: pack | ||
| run: | | ||
| dotnet pack .\windows\libdatadog.csproj -p:LibDatadogBinariesOutputDir=..\bin -p:LibDatadogVersion="42.0.0" -o .nuget\packages\ | ||
|
|
||
| - name: store artifacts | ||
| uses: actions/upload-artifact@v4 | ||
|
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
There was a problem hiding this comment. 🟠 Code VulnerabilityWorkflow depends on a GitHub actions pinned by tag (...read more)When using a third party action, one needs to provide its GitHub path ( No pinned Git ref means the action uses the latest commit of the default branch each time it runs, eventually running newer versions of the code that were not audited by Datadog. Specifying a Git tag is better, but since they are not immutable, using a full length hash is recommended to make sure the action content is actually frozen to some reviewed state. Be careful however, as even pinning an action by hash can be circumvented by attackers still. For instance, if an action relies on a Docker image which is itself not pinned to a digest, it becomes possible to alter its behaviour through the Docker image without actually changing its hash. You can learn more about this kind of attacks in Unpinnable Actions: How Malicious Code Can Sneak into Your GitHub Actions Workflows. Pinning actions by hash is still a good first line of defense against supply chain attacks. Additionally, pinning by hash or tag means the action won’t benefit from newer version updates if any, including eventual security patches. Make sure to regularly check if newer versions for an action you use are available. For actions coming from a very trustworthy source, it can make sense to use a laxer pinning policy to benefit from updates as soon as possible.
|
||
| with: | ||
| name: packages | ||
| path: .nuget/packages/* | ||
| if-no-files-found: error | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,109 @@ | ||
| param ( | ||
| [string]$output_dir, | ||
| [string[]]$targets = @( | ||
| # "aarch64-apple-darwin" | ||
| # "x86_64-apple-darwin" | ||
| # "aarch64-unknown-linux-gnu", | ||
| # "x86_64-unknown-linux-gnu" | ||
| "i686-pc-windows-msvc", | ||
| "x86_64-pc-windows-msvc" | ||
| ) | ||
| ) | ||
|
|
||
| # Check if output directory is set | ||
| if (-not $output_dir) { | ||
| Write-Host "You must specify an output directory with -output. Example: .\build_script.ps1 -output bin" | ||
| exit 1 | ||
| } | ||
|
|
||
| # Make output_dir an absolute path if it's not already | ||
| if (-not [System.IO.Path]::IsPathRooted($output_dir)) { | ||
| $output_dir = Join-Path -Path (Get-Location) -ChildPath $output_dir | ||
| } | ||
|
|
||
| Write-Host "Building project into $output_dir" -ForegroundColor Magenta | ||
|
|
||
| # Function to invoke a command and exit if it fails | ||
| function Invoke-Call { | ||
| param ( | ||
| [scriptblock]$ScriptBlock | ||
| ) | ||
| & $ScriptBlock | ||
| if ($LASTEXITCODE -ne 0) { | ||
| exit $LASTEXITCODE | ||
| } | ||
| } | ||
|
|
||
| # Function to build project with given target, features, and release flag | ||
| function Build-Project { | ||
| param ( | ||
| [string]$target, | ||
| [bool]$release = $false | ||
| ) | ||
|
|
||
| Invoke-Call -ScriptBlock { | ||
| $featues = @( | ||
| "data-pipeline-ffi", | ||
| "datadog-profiling-ffi/ddtelemetry-ffi", | ||
| "datadog-profiling-ffi/crashtracker-receiver", | ||
| "datadog-profiling-ffi/crashtracker-collector", | ||
| "datadog-profiling-ffi/demangler" | ||
| ) | ||
|
|
||
| # cargo has a bug when passing "" as configuration, so branch for debug and release | ||
| if ($release) { | ||
| cargo build --features $($featues -join ",") --target $target --release --target-dir $output_dir | ||
| } else { | ||
| cargo build --features $($featues -join ",") --target $target --target-dir $output_dir | ||
| } | ||
| } | ||
| } | ||
|
|
||
| # Function to generate header files using cbindgen | ||
| function Generate-Header { | ||
| param ( | ||
| [string]$crateName, | ||
| [string]$configPath, | ||
| [string]$outputPath | ||
| ) | ||
|
|
||
| Invoke-Call -ScriptBlock { | ||
| cbindgen --crate $crateName --config $configPath --output $outputPath | ||
| } | ||
| } | ||
|
|
||
| # Build project for multiple targets | ||
|
|
||
| try { | ||
| Push-Location "profiling-ffi" | ||
| foreach ($target in $targets) { | ||
| Build-Project -target $target -release $true | ||
| Build-Project -target $target | ||
| } | ||
| } | ||
| finally { | ||
| Pop-Location | ||
| } | ||
|
|
||
| Write-Host "Building tools" -ForegroundColor Magenta | ||
| try { | ||
| Push-Location "tools" | ||
| Invoke-Call -ScriptBlock { cargo build --release } | ||
| } | ||
| finally { | ||
| Pop-Location | ||
| } | ||
|
|
||
| Write-Host "Generating headers" -ForegroundColor Magenta | ||
|
|
||
| # Generate headers for each FFI crate | ||
| Generate-Header -crateName "ddcommon-ffi" -configPath "ddcommon-ffi/cbindgen.toml" -outputPath "$output_dir\common.h" | ||
| Generate-Header -crateName "datadog-profiling-ffi" -configPath "profiling-ffi/cbindgen.toml" -outputPath "$output_dir\profiling.h" | ||
| Generate-Header -crateName "ddtelemetry-ffi" -configPath "ddtelemetry-ffi/cbindgen.toml" -outputPath "$output_dir\telemetry.h" | ||
| Generate-Header -crateName "data-pipeline-ffi" -configPath "data-pipeline-ffi/cbindgen.toml" -outputPath "$output_dir\data-pipeline.h" | ||
| Generate-Header -crateName "datadog-crashtracker-ffi" -configPath "crashtracker-ffi/cbindgen.toml" -outputPath "$output_dir\crashtracker.h" | ||
|
|
||
| # Deduplicate headers | ||
| Invoke-Call -ScriptBlock { .\target\release\dedup_headers "$output_dir\common.h" "$output_dir\profiling.h" "$output_dir\telemetry.h" "$output_dir\data-pipeline.h" "$output_dir\crashtracker.h" } | ||
|
|
||
| Write-Host "Build finished" -ForegroundColor Magenta |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,115 @@ | ||
| #!/bin/bash | ||
|
|
||
| # Copyright 2021-Present Datadog, Inc. https://www.datadoghq.com/ | ||
| # SPDX-License-Identifier: Apache-2.0 | ||
|
|
||
| # Default values | ||
| output_dir="" | ||
| targets=( | ||
| # Uncomment or add targets as needed | ||
| "aarch64-apple-darwin" | ||
| "x86_64-apple-darwin" | ||
| # "aarch64-unknown-linux-gnu" | ||
| # "x86_64-unknown-linux-gnu" | ||
| # "i686-pc-windows-msvc" | ||
| # "x86_64-pc-windows-msvc" | ||
| ) | ||
|
|
||
| # Parse named parameters | ||
| while [[ "$#" -gt 0 ]]; do | ||
| case "$1" in | ||
| -o|--output) | ||
| output_dir="$2" | ||
| shift 2 | ||
| ;; | ||
| -t|--target) | ||
| targets=() | ||
| shift | ||
| while [[ "$1" && ! "$1" =~ ^- ]]; do | ||
| targets+=("$1") | ||
| shift | ||
| done | ||
| ;; | ||
| *) | ||
| echo "Unknown parameter: $1" | ||
| exit 1 | ||
| ;; | ||
| esac | ||
| done | ||
|
|
||
| # Check if output directory is set | ||
| if [ -z "$output_dir" ]; then | ||
| echo "You must specify an output directory with -o or --output. Example: ./build_script.sh -o bin" | ||
| exit 1 | ||
| fi | ||
|
|
||
| # Make output_dir an absolute path if it's not already | ||
| if [[ "$output_dir" != /* ]]; then | ||
| output_dir="$(pwd)/$output_dir" | ||
| fi | ||
|
|
||
| echo -e "Building project into $output_dir" | ||
|
|
||
| # Function to invoke a command and exit if it fails | ||
| invoke_call() { | ||
| "$@" | ||
| if [ $? -ne 0 ]; then | ||
| exit $? | ||
| fi | ||
| } | ||
|
|
||
| # Function to build project with given target, features, and release flag | ||
| build_project() { | ||
| local target="$1" | ||
| local release_flag="$2" | ||
|
|
||
| features=( | ||
| "data-pipeline-ffi" | ||
| "datadog-profiling-ffi/ddtelemetry-ffi" | ||
| "datadog-profiling-ffi/crashtracker-receiver" | ||
| "datadog-profiling-ffi/crashtracker-collector" | ||
| "datadog-profiling-ffi/demangler" | ||
| ) | ||
|
|
||
| if [ "$release_flag" = "--release" ]; then | ||
| invoke_call cargo build --features "$(IFS=,; echo "${features[*]}")" --target "$target" --release --target-dir "$output_dir" | ||
| else | ||
| invoke_call cargo build --features "$(IFS=,; echo "${features[*]}")" --target "$target" --target-dir "$output_dir" | ||
| fi | ||
| } | ||
|
|
||
| # Function to generate header files using cbindgen | ||
| generate_header() { | ||
| local crate_name="$1" | ||
| local config_path="$2" | ||
| local output_path="$3" | ||
|
|
||
| invoke_call cbindgen --crate "$crate_name" --config "$config_path" --output "$output_path" | ||
| } | ||
|
|
||
| # Build project for multiple targets | ||
| pushd profiling-ffi || exit | ||
| for target in "${targets[@]}"; do | ||
| build_project "$target" "--release" | ||
| build_project "$target" "" | ||
| done | ||
| popd || exit | ||
|
|
||
| echo -e "Building tools" | ||
| pushd tools || exit | ||
| invoke_call cargo build --release | ||
| popd || exit | ||
|
|
||
| echo -e "Generating headers" | ||
|
|
||
| # Generate headers for each FFI crate | ||
| generate_header "ddcommon-ffi" "ddcommon-ffi/cbindgen.toml" "$output_dir/common.h" | ||
| generate_header "datadog-profiling-ffi" "profiling-ffi/cbindgen.toml" "$output_dir/profiling.h" | ||
| generate_header "ddtelemetry-ffi" "ddtelemetry-ffi/cbindgen.toml" "$output_dir/telemetry.h" | ||
| generate_header "data-pipeline-ffi" "data-pipeline-ffi/cbindgen.toml" "$output_dir/data-pipeline.h" | ||
| generate_header "datadog-crashtracker-ffi" "crashtracker-ffi/cbindgen.toml" "$output_dir/crashtracker.h" | ||
|
|
||
| # Deduplicate headers | ||
| invoke_call ./target/release/dedup_headers "$output_dir/common.h" "$output_dir/profiling.h" "$output_dir/telemetry.h" "$output_dir/data-pipeline.h" "$output_dir/crashtracker.h" | ||
|
|
||
| echo -e "Build finished" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🟠 Code Vulnerability
No explicit permissions set for at the workflow level (...read more)
Datadog’s GitHub organization defines default permissions for the
GITHUB_TOKENto be restricted (contents:read,metadata:read, andpackages:read).Your repository may require a different setup, so consider defining permissions for each job following the least privilege principle to restrict the impact of a possible compromise.
You can find the list of all possible permissions in Workflow syntax for GitHub Actions - GitHub Docs. They can be defined at the job or the workflow level.