Add packages to support deadsnakes Python install in jobs #67
No reviewers
Labels
No Label
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
Copied from Github
Kind/Breaking
Kind/Bug
Kind/Documentation
Kind/Enhancement
Kind/Feature
Kind/Security
Kind/Testing
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Reviewed
Confirmed
Reviewed
Duplicate
Reviewed
Invalid
Reviewed
Won't Fix
Status
Abandoned
Status
Blocked
Status
Need More Info
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: cerc-io/hosting#67
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "dboreham/deadsnakes-fixes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When trying to get our CI jobs to run on ARM Linux I found that the stock python action uses a binary repository that has no builds for aarch64/Linux. The recommended workaround is to use a different action that instead pulls from a Debian package repository containing Python packages for various versions and architectures, called deadsnakes.
While in theory that would solve the problem, it turned out to create yet more problems. This PR addresses those by adding the
sudo
command to the runner container, and a package to supply the command used to add a new apt repo. In addition, because the Python package install in turn triggers the installation of the tzdata package that ends up looking for user input (and the use of sudo thwarts the usual workaround), this PR sets the container time zone. This has the side affect of skipping the user input step.You might ask why we should install random stuff in our runner container like this, for a specific github action? Normally that wouldn't be appropriate, however since the deadsnakes action appears to be fairly widely used, my assumption is that the Ubuntu runners at GitHub must have these various pieces already installed. On that basis (parity with GitHub runner environment) I think it makes sense.