another way to fix tests is to set the timezone to UTC:
env TZ=UTC paru aws-cli-v2
Git Clone URL: | https://aur.archlinux.org/aws-cli-v2.git (read-only, click to copy) |
---|---|
Package Base: | aws-cli-v2 |
Description: | Unified command line interface for Amazon Web Services (version 2) |
Upstream URL: | https://github.com/aws/aws-cli/tree/v2 |
Licenses: | Apache |
Conflicts: | aws-cli |
Provides: | aws-cli |
Submitter: | jelly |
Maintainer: | kino_t |
Last Packager: | kino_t |
Votes: | 12 |
Popularity: | 8.59 |
First Submitted: | 2024-04-21 11:04 (UTC) |
Last Updated: | 2024-05-15 22:58 (UTC) |
another way to fix tests is to set the timezone to UTC:
env TZ=UTC paru aws-cli-v2
No, users should not be responsible for running the test suite for every package they install on their system. They can if they want but it certainly shouldn't be the default.
The tests are run during development, integration, and release. Re-testing an already tested release on every install is a waste of time and compute resources.
For paru
, use --nocheck
to skip the check()
function which contains the tests:
paru -S --aur --noconfirm --nocheck aws-cli-v2
Solved by !check in makepkg.conf
This should be mentioned in a pinned comment.
in respect to https://docs.aws.amazon.com/cli/latest/userguide/getting-started-version.html , the key A6310ACC4672475C has to be added with gpg
disabling checks in yay can be done like this
yay -S package-name --mflags "--nocheck"
I never get to install this pkg due to test failures.
So frustrated, I'm going to release bin version of this pkg.
--nocheck
is not supported on yay
.
These tests are there for the developers of aws-cli to ensure features built are actually working and no regressions are introduced from version to version; they're not really meant as target platform integration tests.
So, when a test failure would occur, there wouldn't be a new release since that would've been caught on upstream side already. As such you could argue it is not really necessary to run them on package build.
However, the package does patch quite some stuff, so after all it is justified a bit. It seems, though, that these tests do pick up the environment and user-specific configuration that exists in the context where these tests are run. For the package it means it uses all env vars and $HOME/.aws/{credentials,config}
and that really is a problem since many of us might have real credentials there...
These tests should have some kind of jail and a separate user where they're run (eg. for me the test suite finally breaks with an assertion that 'eu-central-1' != 'us-mars-2'
- where eu-central-1 is the region configured in my $HOME/.aws/credentials).
PS: Thank you for providing this package!
UPDATE: Found out that you can build packages in a chroot, with paru's --chroot
option and this solves everything. I will enable this option in /etc/paru.conf
for all the builds.
@asday I understand your concern but this is relevant for people with exotic architectures or configuration. They should be able to opt-in for tests. In my case it is classic amd64. I believe that python is bad enough to misbehave but the probability in real world is low when you are using "classic amd64 environment".
Opt-in for tests is good for some users but so is opt-out. Users need to decide themselves. I did so I turned off tests. Yes it can break but so my whole system can break with every kernel update. Do you run tests for kernel?
Do you run tests in Docker? I believe that most production use of aws cli is in Docker environment.
Pinned Comments
GrzegorzKozub commented on 2024-05-14 05:28 (UTC)
For
paru
, use--nocheck
to skip thecheck()
function which contains the tests:ksuhiyp commented on 2024-05-06 11:19 (UTC)
disabling checks in yay can be done like this
yay -S package-name --mflags "--nocheck"