`service_account_email` defaults to None if one
is not set. For gcp_compute_instance_info, this results
in an invalid request as the service account is populated
directly in the path.
Populating `default` when a value is not set fixes the error.
fixes#568
The test is still flakey currently. A few attempts have
been made to fix it, but it seems that the bigtable API
does not consistently return the resource after is has
been created.
While exploring ways to make it more robust, disabling the
test to keep the CI tests from being unreliable to the point
of useless.
The version_added field is documented for a very small set of
fields, specifically in gcp_compute today.
Removing these values as they are specifying the ansible-core version
which is confusing for those who are installing via ansible-galaxy,
and the value is not set for any other module.
fixes#550.
ansible-lint was updated and the GitHub
action did not pin the dependency, resulting
in the repository to fail sanity tests.
Updating the repository to adhere to new fatal
linter rules, but also pinning the linter to
prevent failures that may be unrelated to the
particular commit.
Updating usages for python3.8 to 3.9 as ansible-lint
is dropping support for 3.8.
commit ccbde5f93e introduced
a backwards-incompatible change which made ansible-inventory
no longer recognize `gcp_compute` as a valid package name.
This would break users who are use `gcp_compute` (instead of the
new `google.cloud.gcp_compute`). Accepting both until at least
a major version change.
fixes#536.
Ansible-lint is required for Ansible collection
certification for Automation Hub.
gcsfuse had no metadata associated with it, failing
the Ansible Hub upload.
Updating the maintainers guide with updated intructions from
Ansible engineers.
Fixing linting issues, and adding the linter as a GitHub workflow
to ensure there are no regressions.
the previous fix had invalid syntax (hard to test against the
master branch until after push).
This syntax is documented as correct:
https://github.com/actions/runner/issues/950
The client's List continues to be flakey. disabling until
the endpoint is stable.
Switching tests to use ansible 2.14, as 2.13 has issues with
spawning a docker container.
Upgrading the base python version as a consequence.
Removing the need for docker from unit tests, since that was failing
and also non-critical to run unit tests.
- Updating and documenting changelog creation process.
antsibull-changelog was chosen because it is the standard tooling
recommended by Ansible developers.
- Documenting the release process and several others so others can perform it in the
future.
- Updating the integration tests to test against 2.13, which the 1.1.0
final release will be certified for.
- Created changelog and update galaxy.yaml for 1.1.0-beta, which will be
the next release.
Ansible role tests were failing due to ansible-lint reporting
multiple errors.
Fixing those errors resolves the failing tests.
Switching gcsfuse to use gcloud's bootstrap to follow the current
docker install instructions.
Removing centos as it's a discontinued distribution.
Adding a check to ensure integration tests are skipped unless they
are run by a branch (a public fork does not pass required
integration test credentials).
Some test cases are unsupported due to environmental or
blocking code restrictions (e.g. unimplemented dependent resources).
As these will likely not be fixed before the first release certified
for Ansible 2.11 and beyond, documenting them instead.
The spanner List API is returning intermittent 404s, which
is resulting in the spanner_database test failing every other
time.
Disabling the API until the test is more stable.
bigtableadmin was not enabled in the bootstrapping script.
Also running the bootstrap script on every CI run, to ensure
the test environment is properly set up.
gcp_spanner_database erroneously used LRO handling on delete,
rather than a standard synchronous function. One side effect
was not catching 404s as a not found error code.
skip_initial_version_creation previously defaulted to None,
which results in an invalid value in the create call to
gcp_kms_crypto_key.
Defaulting to False fixes the issue.
Incorporating a fix for GKE 1.19+ (See #444).
Inlined:
Google has removed basic-auth method from within GKE starting version 1.19
This lead the output response of the backend API not to provide basic-auth
data (username and password) anymore.
The current implementation of gcp_container_cluster when generating the kubectl
config file, always set basic-auth data w/o checking if there actually are
available or explicitly provided even when the value are not set/provided
from gcp_container_cluster.
In addition, re-enabling some tests that #444 fixed.
Co-authored-by: Xavier Lamien <laxathom@lxtnow.net>
fixing a flakey service account test. Sometimes the service account
generated can be less than 6 characters (e.g. sa-57), which is an
invalid length.
This ensures that the name is at least 6 characters.
- vpn_gateway required minimal changes (stop using legacy load
balancers)
- compute_vpn_tunnel requires a valid vpn configuration
(several dependent forwarding rules and configuration to set up a
proper tunnel).
the following tests can be enabled without any changes:
- gcp_compute_target_http_proxy
- gcp_compute_target_https_proxy
- gcp_compute_target_ssl_proxy
- gcp_compute_target_tcp_proxy
The backend_service resource was not regional, which is in invalid
configuration for a regional proxy to depend on.
Fixing up cleanup-script to better handle region/ global resources.
