-
Notifications
You must be signed in to change notification settings - Fork 139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
add unix specific execution permission to tp binary executable #1293
add unix specific execution permission to tp binary executable #1293
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1293 +/- ##
==========================================
- Coverage 19.30% 17.39% -1.91%
==========================================
Files 164 163 -1
Lines 10849 10675 -174
==========================================
- Hits 2094 1857 -237
- Misses 8755 8818 +63
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Bencher Report
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
97140b4
to
971ee7b
Compare
@Shourya742 can you please edit the PR description with a detailed description of:
|
Done |
164be11
to
712e1dd
Compare
@Shourya742 it seems we changed the approach here? can we get a description of this new approach? (overall let's try to keep PRs descriptive, otherwise the review process becomes guesswork, which is not really ideal) |
tbh I'm not a fan of slapping therefore I feel it's important to have a detailed understanding on why we are doing this... and most importantly: why did we pivot away from the original approach? |
The reason why we pivoted from the original approach because it didn't worked. The issue was only happening when we were running the actions for the very first time when we open a PR (though via rerun it worked). I didn't get why using sudo is dirty??We use sudo because the tests access the /tmp directory, which encounters permission issues on GitHub's macOS runners. This ensures the necessary access to directories like /tmp during the workflow execution. This is the issue with macos runner, not our code. |
even tests that have nothing to do with the original problem (
slapping |
Right now, sudo is only applied to tests that somehow trigger roles/test, since the integration test is directly invoked when we run tests on roles. I’ve added sudo to the other Test actions just to keep the pattern consistent, but I can change that if it’s causing any confusion. |
the original solution description was:
our solution needs to encompass the scope of this problem without overescalating execution to we can achieve that with: - name: Roles Integration Tests (MAC)
if: matrix.os == 'macos-latest'
run: |
xattr -d com.apple.quarantine /tmp/.template-provider/bitcoin-sv2-tp-*/bin/bitcoin*
cargo test --manifest-path=roles/Cargo.toml --verbose --test '*' -- --nocapture the the point here is that we are fixing the problem with a specific solution, instead of an umbrella with potential unintended consequences. |
This I did via code in my previous solution, but it didn't worked. |
it didn't work because the rust executable doesn't (and most importantly: shouldn't) have priviledged execution the suggestion above is to achieve this via |
Won't this fail, as the directory |
I see your point. Perhaps instead of calling - name: Roles Integration Tests (MAC)
if: matrix.os == 'macos-latest'
run: |
sudo mkdir -p /tmp/.template-provider
sudo chmod 777 /tmp/.template-provider
cargo test --manifest-path=roles/Cargo.toml --verbose --test '*' -- --nocapture this approach tweaks permissions from a different perspective: we just create a then we shouldn't even need to tweak write permissions for the note: this is just a sketch, the commands could potentially look slightly different |
I observed another failure condition, apart from the one mentioned, which occurs during the prop test. Fortunately, I believe this is happening because of the latest macOS runner. I changed its version to 14, and now everything works. |
I think the current approach is much better. a few remarks:
|
c765ec6
to
6157916
Compare
Done and updated |
closes #1278
The error Permission denied (os error 13) indicates that your process does not have the necessary permissions to execute the bitcoind binary located at /tmp/.template-provider/bitcoin-sv2-tp-0.1.9/bin/bitcoind
Solution: changing macos runner version worked