kustomize doesn't fully support resource url query parameters

[annasong20]

Describe the bug
Our remote targets specification describes optional query string parameters. However, kustomize cannot currently handle certain parameter combinations. For example, I observe an error on my machine when:

1. url has no parameters
2. https url to directory in repo has parameter ref=master

These parameter combinations behave unreliably on the server, throwing an error only occasionally. We need to debug this issue.

Files that can reproduce the issue
TestRemoteResourceParameters contains 3 test cases that output errors on my machine because of the parameters in the urls.

We skip the tests https no params and https master because though they throw errors consistently locally, the tests throw errors inconsistently on the server for an unknown reason.

Note that the ssh no params test may behave unreliably on the server as well, we just do not see this behavior because the server does not yet have ssh keys #4620 and thus we must skip this test.

Expected output
We expect the 3 sub-tests in TestRemoteResourceParameters that currently throw errors to output the configuration string in variable multibaseDevExampleBuild.

Actual output
The current output on my machine of each sub-test is what's written in the test cases. The test cases specify the prefix of the error strings produced by the urls.

The output on the server is sporadic. kustomize build sometimes throws errors and other times does not.

Kustomize version
kustomize behaves this way on the master branch, which is on commit 17b42a9.

Platform
I work on macOS. The tests fail on the macOS server, but pass on Linux.

[KnVerey]

/triage accepted

[olegsu]

/assign

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.