-
Notifications
You must be signed in to change notification settings - Fork 693
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
Runs fetch-tor-packages with pinned version in CI #4300
Conversation
b8b4371
to
b99ce8e
Compare
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.
I've rebased this branch on latest develop
to address linting container issues (#4301), and proceeded with the following test plan:
Testing
- Confirm
make fetch-tor-packages
passes locally - ❌ Confirm CI is passing
In the current, it seems like the venv isn't preserved across ssh sessions: https://circleci.com/gh/freedomofpress/securedrop/25033
Wrapping the molecule command in a shell script and bootstrapping the venv (285d4df4f1c7) seems to get us further.
However, there's another failure that is likely due to the fact we are rsyncing of the repo to the gce instance instead of cloning it, as we do in workstations: https://github.com/freedomofpress/securedrop/blob/develop/devops/gce-nested/gce-runner.sh#L40 see https://circleci.com/gh/freedomofpress/securedrop/25040
Perhaps we can sidestep by using it locally inside the circle container (as part of this or another job) and not via ssh_gce
?
Great comments, @emkll. I agree a separate job would be better for a few reasons, including parallel execution. Pushed a trial commit based on your examples, will follow up once we have feedback from the CI system. Marking as WIP for now, until we confirm CI is passing. |
Adds a `tor_version` var to the fetch-tor-packages logic. This is yet another point of update when we bump versions, but pinning will help us avoid surprises. To that end, we're also running the fetch action in CI now, to help us catch version mismatches earlier. Using a separate CI job so as not to add to the serial execution of the large staging job.
2f2ac01
to
a90f731
Compare
CI passed on the fetch tor packages logic here: https://circleci.com/gh/freedomofpress/securedrop/25052 So I've squashed the commits. Once you confirm CI is passing here, @emkll, I'd appreciate a sanity check that the |
Confirm fetch logic working for me locally, unfortunately since kernels have been uploaded to apt-test, #4308 needs to be merged in first and this branch rebased on top of that commit.
Re-running CI after merge of #4308. |
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.
LGTM:
- Confirm
make fetch-tor-packages
passes locally - Confirm CI is passing
- Theres a new check for fetch-tor-debs
Status
Ready for review.
Description of Changes
Closes #4170.
Adds a
tor_version
var to the fetch-tor-packages logic. This is yet another point of update when we bump versions, but pinning will help us avoid surprises. To that end, we're also running the fetch action in CI now, to help us catch version mismatches earlier.Testing
make fetch-tor-packages
passes locallyDeployment
No concerns, dev env tooling only. There's a modest improvement in reliability in the release window, ensuring we fetch the same package version we've been testing.
Checklist
If you made non-trivial code changes: