Fix test_auth_environ_raises integration test

[jrbourbeau]

This is currently failing on main with FAILED tests/integration/test_api.py::test_auth_environ_raises - Failed: DID NOT RAISE <class 'RuntimeError'> (for example, see this CI build) due to the new automatic authentication update (xref #300).

This PR update this test accordingly so it passes while still keeping the original intent of the test

[github-actions]

👈 Launch a binder notebook on this branch for commit 709c10d

I will automatically update this comment whenever this PR is modified

👈 Launch a binder notebook on this branch for commit 5517c56

👈 Launch a binder notebook on this branch for commit 234f9af

[MattF-NSIDC]

LGTM, but I felt the comment could use a touch more detail :)

Any idea why this didn't fail on the feature branch prior to merge?

[jrbourbeau]

Any idea why this didn't fail on the feature branch prior to merge?

Integration tests aren't run on PRs, only pushes to main

earthaccess/.github/workflows/integration-test.yml

Lines 3 to 11 in d0386ae

	on:
	push:
	branches:
	- main
	paths:
	- earthaccess/**
	- tests/**
	- docs/**
	- binder/**

[MattF-NSIDC]

OT: Any opinions on setting up integration tests to also run on workflow_dispatch or in response to a comment in a PR? Would be good for certain changes to be able to manually trigger the integration tests on a feature branch. (cc @betolink)

[jrbourbeau]

The main issue is the integration tests are using repo secrets, which aren't available on forks, only the base nsidc/earthaccess repo. I'm sure we could find some way around this, but I'm skeptical it will be worth the effort (could be wrong about that though).

I think increased visibility into when integration tests fail would help. Over in dask we have a similar CI build that run on pushes to main + a nightly cron and we use this logic to open an issue when there's a failure. That way we at least get a ping when there's a failure. Maybe something similar here would be useful.

[MattF-NSIDC]

Great points! To be clear, the event type which protects secrets from forks is pull_request. If we trigger on a PR comment, the event type would be issue_comment, and we should be very careful that our workflow checks the commenter is a repository member before running the workflow. The triggering user would also have to be aware of the importance of reviewing the PR for malicious code before triggering the workflow. That last part makes this far from an ideal choice :)