ci: test on different architectures#114
Conversation
james-garner-canonical
force-pushed
the
25-10+ci+test-on-different-architectures
branch
3 times, most recently
from
e8788c5 to
a9f2a86
Compare
james-garner-canonical
force-pushed
the
25-10+ci+test-on-different-architectures
branch
2 times, most recently
from
6184420 to
4455749
Compare
james-garner-canonical
force-pushed
the
25-10+ci+test-on-different-architectures
branch
from
4455749 to
5ae71ca
Compare
Merge branch 'main' into 25-10+ci+test-on-different-architectures
james-garner-canonical
force-pushed
the
25-10+ci+test-on-different-architectures
branch
from
4c24065 to
ef4b938
Compare
| if systemctl is-enabled unattended-upgrades.service; then | ||
| systemctl stop unattended-upgrades.service | ||
| systemctl stop unattended-upgrades.service || echo 'Self-hosted runner?' | ||
| systemctl mask unattended-upgrades.service | ||
| fi |
There was a problem hiding this comment.
Oddly the if systemctl is-enabled unattended-upgrades.service conditional does not guard from failure when stopping the service on the self-hosted runners.
+ systemctl is-enabled unattended-upgrades.service
unattended-upgrades.service is not a native service, redirecting to systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install is-enabled unattended-upgrades
enabled
+ systemctl stop unattended-upgrades.service
Failed to stop unattended-upgrades.service: Unit unattended-upgrades.service not loaded.
8424b00 to
5d2f3f9
Compare
Merge branch 'main' into 25-10+ci+test-on-different-architectures
|
The |
|
A number of jobs fail on s390x due to what appear to be network things and timeouts. Rerunning the failing tests leads to only the expected I'll disable that test on the alternative architectures and rerun them again. I wonder if we'll see network issues and timeouts again due to increased load on the self-hosted runner when running all the spread jobs in parallel (rather than only the failing ones in that rerun). |
|
We do indeed see two such failures, one failure to install a snap, and one timeout doing I'm-not-sure-what. Rerunning the failed jobs, they pass. |
|
Another random failure to install a snap, but the other jobs all succeeded. |
…API client (canonical#123) Avoid using the snapcore/snapd Go code directly, in favour of the official REST API. The Snap team feel that there is a lot of code outside of `internal` that should be moved to `internal` before there could be standard Go versioning and officially supported use of the Go client by other Go packages like Concierge. This change reduces the number of dependencies (one direct, 18 transitive), moves to an officially supported and documented interface for snapd, and solves an issue where security scanners (Dependabot, Trivy) don't understand snapd's revision-based versioning, causing persistent false positives for already-fixed vulnerabilities. ## Changes **New snapd API client** (`internal/snapd/client.go`): - Dedicated `internal/snapd` package separate from system package - HTTP client communicating directly with `/run/snapd.socket` via Unix domain sockets - `Snap()` method for querying installed snaps - `FindOne()` method for searching the snap store - Minimal JSON response structures (only fields we consume) ## Example Before: ```go import client "github.com/snapcore/snapd/client" snapd := *client.New(nil) snap, _, err := snapd.FindOne(name) ``` After: ```go import "github.com/canonical/concierge/internal/snapd" client := snapd.NewClient(nil) snap, err := client.FindOne(name) ``` The API surface remains unchanged - only the implementation backing `System.SnapInfo()` and `System.SnapChannels()` differs. - Fixes canonical#101 <!-- START COPILOT CODING AGENT TIPS --> --- 💬 We'd love your input! Share your thoughts on Copilot coding agent in our [2 minute survey](https://gh.io/copilot-coding-agent-survey). --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: tonyandrewmeyer <826522+tonyandrewmeyer@users.noreply.github.com> Co-authored-by: Tony Meyer <tony.meyer@canonical.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ben Hoyt <ben.hoyt@canonical.com> Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
[security@ubuntu.com](mailto:security@ubuntu.com) PGP key has been rotated. Please see [this section](https://wiki.ubuntu.com/SecurityTeam/FAQ#Contact) on the Ubuntu wiki. The old and the new key have been cross-signed and uploaded to the Ubuntu keyserver. In the future, it might be worth referring directly to the corresponding section in the [Ubuntu disclosure policy page](https://ubuntu.com/security/disclosure-policy#contact-us) (please note that we're in the process of updating the key there).
…cal#146) Splits out development / hacking / contributing information from README.md into a new CONTRIBUTING.md file (this is done as the first commit, if you want to see that it's just moving existing content). Adds new content to CONTRIBUTING.md: * General welcoming content, heavily based on canonical/operator * Explain the Charm Tech approach to PRs including conventional commits * Add a statement about using AI (essentially the same as canonical/operator) * Add instructions for making a release (based on Pebble, but with the steps used here) --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Ben Hoyt <benhoyt@gmail.com>
tonyandrewmeyer
left a comment
tonyandrewmeyer
left a comment
There was a problem hiding this comment.
Sorry for being quite slow with this review.
I'm on board overall with adjusting the integration tests to be less K8s'y, since we seem to still be covering all the functionality, and we want lxd and k8s to equally work. There is one case I'd rather keep as-is or change in a different way.
Two bits that have changed in main since you did this and haven't been caught in merging.
Otherwise, I'm fine with this. Thanks for all the arduous work!
Merge branch 'main' into 25-10+ci+test-on-different-architectures
|
Ironically, after not failing at all over the course of this PR, the regular spread tests on the Github hosted runners have had two failures this run, right as I added the matrix test collection job :( But at least this shows that the |
Co-authored-by: James Garner <james.garner@canonical.com>
Co-authored-by: James Garner <james.garner@canonical.com>
james-garner-canonical
merged commit 976a441
into
canonical:main
This PR adds a reusable workflow that can run our
spreadtests on the specified architecture and runner, and adds a manually dispatchable workflow that uses this worfklow to run tests across the alternative architecturesppc64le, ands390x.push.yamlto_tests.yaml, andpush.yamlhas been updated to call it foramd64._tests.yamlupdates the test logic to accept the runner and architecture, building theconciergebinary for the target architecture on Github'subuntu-latest.spreadwith ourconciergebinary on the correct runner --ubuntu-latestforamd64, and our self-hosted runners forppc64leands390x.The
k8ssnap doesn't support these alternative architectures yet (tracked in canonical/k8s-snap#2076, PR in progress by maintainers at canonical/k8s-snap#1980, but support may be incomplete even if builds are provided). To keep CI green and useful, I've added logic to the workflow to skip the tests that requirek8sbased on the architecture, and updated several of the tests that usedk8sbut weren't testing anything K8s-specific to uselxdinstead.This PR changes the job names run in CI, and the required checks have been updated accordingly.
Resolves #76.