- Sourcegraph version: 3.39
- Platform information: AWS EC2, internal test instance (hosted at cse-aws-test.sgdev.org).Docker-compose deployment.
Steps to reproduce:
(Steps with screenshots shared in Slack, and re-described below.)
- Create a brand new code host configuration
- Add a public repo. Do not alter the "token" field whatsoever.
3/BUG. Sourcegraph accepts the configuration as valid.
SYMPTOMS:
(A) The repo that was ostensibly "added" is not discoverable in the "Repository Status" page. This would be confusing.
(B) When adding a non-consequential edit to the faulty code-host configuration (e.g. adding whitespace), the page does respond that credentials were bad. This is good , but might be confusing to someone who, say, did not touch credentials during their edit.
(C) When making no changes to the faulty code-host configuration page, the page does not respond that credentials were bad.
Expected behavior:
Between steps 2 and 3, I would expect some sort of validation to occur.
For symptom C, I would expect some sort of validation to occur (though, I guess, at this point, we might assume that the config had passed our initial validation).
Actual behavior:
The user is able to neglect adding an access token, and is not immediately warned.
If would like immediate help on this, please email support@sourcegraph.com (you can still create the issue, but there are not SLAs on issues like there are for support requests).
Steps to reproduce:
(Steps with screenshots shared in Slack, and re-described below.)
3/BUG. Sourcegraph accepts the configuration as valid.
SYMPTOMS:
(A) The repo that was ostensibly "added" is not discoverable in the "Repository Status" page. This would be confusing.
(B) When adding a non-consequential edit to the faulty code-host configuration (e.g. adding whitespace), the page does respond that credentials were bad. This is good , but might be confusing to someone who, say, did not touch credentials during their edit.
(C) When making no changes to the faulty code-host configuration page, the page does not respond that credentials were bad.
Expected behavior:
Between steps 2 and 3, I would expect some sort of validation to occur.
For symptom C, I would expect some sort of validation to occur (though, I guess, at this point, we might assume that the config had passed our initial validation).
Actual behavior:
The user is able to neglect adding an access token, and is not immediately warned.
If would like immediate help on this, please email support@sourcegraph.com (you can still create the issue, but there are not SLAs on issues like there are for support requests).