internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: ansible/awx

Issue:
[api] Confusing error when trying to sync project set to scm_type Manual
### Please confirm the following

- [X] I agree to follow this project's [code of conduct](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html).
- [X] I have checked the [current issues](https://github.com/ansible/awx/issues) for duplicates.
- [X] I understand that AWX is open source software provided for free and that I might not receive a timely response.

### Bug Summary

Creating a project and accidentally setting it to be `scm_type: manual` (the default in the awx collection), and then trying to do a project update on it, leads to a very confusing error:

```
fatal: [localhost]: FAILED! => {"changed": false, "msg": "Cannot make a request with the POST method to this endpoint /api/v2/projects/8/update/"}
```

Although it is "technically" correct, it would be nice if we could show something nicer in this scenario (e.g. "Unable to trigger a project update because the project scm type (Manual) does not support it.")

### AWX version

devel

### Select the relevant components

- [ ] UI
- [X] API
- [ ] Docs
- [ ] Collection
- [ ] CLI
- [ ] Other

### Installation method

docker development environment

### Modifications

no

### Ansible version

_No response_

### Operating system

_No response_

### Web browser

_No response_

### Steps to reproduce

- Create a project, set its type to Manual
- Use the API (or `awx.awx.project_update`) to try to update it

### Expected results

An error explaining the problem

### Actual results

An error telling me that I can't POST to an endpoint that I expect to be able to POST to.

### Additional information

_No response_


Discussion:
Hi team. Can I work on this if none is doing it?
If I understand correctly, we need to fix around here.
https://github.com/ansible/awx/blob/e0b1274eee44bb47114b74c07c2ad5331f28cacf/awx_collection/plugins/modules/project_update.py#L114-L115

I've started working on this issue. 

Resolving patch:
diff --git a/awx_collection/plugins/modules/project_update.py b/awx_collection/plugins/modules/project_update.py
--- a/awx_collection/plugins/modules/project_update.py
+++ b/awx_collection/plugins/modules/project_update.py
@@ -114,7 +114,12 @@ def main():
     # Update the project
     result = module.post_endpoint(project['related']['update'])
 
-    if result['status_code'] != 202:
+    if result['status_code'] == 405:
+        module.fail_json(
+            msg="Unable to trigger a project update because the project scm_type ({0}) does not support it.".format(project['scm_type']),
+            response=result
+        )
+    elif result['status_code'] != 202:
         module.fail_json(msg="Failed to update project, see response for details", response=result)
 
     module.json_output['changed'] = True


Test patch:
Repository: ansible/awx

Issue:
Exception handling for Conjur Secrets Manager Lookup not working properly
### Please confirm the following

- [X] I agree to follow this project's [code of conduct](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html).
- [X] I have checked the [current issues](https://github.com/ansible/awx/issues) for duplicates.
- [X] I understand that AWX is open source software provided for free and that I might not receive a timely response.

### Bug Summary

When using the Conjur Secrets Manager Lookup credential type against Conjur Cloud, exception handling does not properly switch to the proper URI endpoint automatically.  Any attempts currently fail with HTTP 404.

### AWX version

0.1.dev32763+g3d73b80

### Select the relevant components

- [X] UI
- [ ] API
- [ ] Docs
- [ ] Collection
- [ ] CLI
- [ ] Other

### Installation method

docker development environment

### Modifications

no

### Ansible version

_No response_

### Operating system

_No response_

### Web browser

_No response_

### Steps to reproduce

1. Select "CyberArk Conjur Secrets Manager Lookup" as the credential type for a new credential object in AWX.
2. Configure for a Conjur Cloud tenant.
3. Run "Test" and a failure with "HTTP 404" is returned.

### Expected results

The test should pass.

### Actual results

The test fails with an HTTP 404 error code.

### Additional information

This fix is being implemented in a PR within moments.


Discussion:

Resolving patch:
diff --git a/awx/main/credential_plugins/conjur.py b/awx/main/credential_plugins/conjur.py
--- a/awx/main/credential_plugins/conjur.py
+++ b/awx/main/credential_plugins/conjur.py
@@ -70,7 +70,8 @@ def conjur_backend(**kwargs):
         auth_kwargs['verify'] = cert
         try:
             resp = requests.post(urljoin(url, '/'.join(['authn', account, username, 'authenticate'])), **auth_kwargs)
-        except requests.exceptions.ConnectionError:
+            resp.raise_for_status()
+        except requests.exceptions.HTTPError:
             resp = requests.post(urljoin(url, '/'.join(['api', 'authn', account, username, 'authenticate'])), **auth_kwargs)
     raise_for_status(resp)
     token = resp.content.decode('utf-8')
@@ -92,7 +93,8 @@ def conjur_backend(**kwargs):
         lookup_kwargs['verify'] = cert
         try:
             resp = requests.get(path, timeout=30, **lookup_kwargs)
-        except requests.exceptions.ConnectionError:
+            resp.raise_for_status()
+        except requests.exceptions.HTTPError:
             resp = requests.get(path_conjurcloud, timeout=30, **lookup_kwargs)
     raise_for_status(resp)
     return resp.text


Test patch:
Repository: ansible/awx

Issue:
awx.awx.workflow_job_template parameter destroy_current_nodes does not show "changed" status
### Please confirm the following

- [X] I agree to follow this project's [code of conduct](https://docs.ansible.com/ansible/latest/community/code_of_conduct.html).
- [X] I have checked the [current issues](https://github.com/ansible/awx/issues) for duplicates.
- [X] I understand that AWX is open source software provided for free and that I might not receive a timely response.

### Bug Summary

When using the awx.awx.workflow_job_template module and the parameter 'destroy_current_nodes: true', Ansible returns 'ok' status even though the item was very much changed as all of the workflow nodes are removed.

This should return a 'changed' status to properly indicate that something was modified on the workflow.

### AWX version

21.7.0

### Select the relevant components

- [ ] UI
- [ ] API
- [ ] Docs
- [X] Collection
- [ ] CLI
- [ ] Other

### Installation method

kubernetes

### Modifications

no

### Ansible version

2.13.7

### Operating system

_No response_

### Web browser

_No response_

### Steps to reproduce

Task using awx.awx.workflow_job_template
Set parameter 'destroy_current_nodes: true'


### Expected results

Status would be 'changed' since all existing nodes in the workflow were removed

### Actual results

Status is 'ok' and all existing nodes in the workflow were removed

### Additional information

_No response_


Discussion:

Resolving patch:
diff --git a/awx_collection/plugins/modules/workflow_job_template.py b/awx_collection/plugins/modules/workflow_job_template.py
--- a/awx_collection/plugins/modules/workflow_job_template.py
+++ b/awx_collection/plugins/modules/workflow_job_template.py
@@ -991,6 +991,7 @@ def main():
     # Destroy current nodes if selected.
     if destroy_current_nodes:
         destroy_workflow_nodes(module, response, workflow_job_template_id)
+        module.json_output['changed'] = True
 
     # Work thorugh and lookup value for schema fields
     if workflow_nodes:


Test patch:
Repository: dbt-labs/dbt-core

Issue:
Spelling errors/typos in schema.sql are not caught
I had misspelled `constraints` as `contraints` for a couple of weeks, and didn't catch it. Expectation is that whatever's parsing the YAML would verify and throw a warning or error if there are fields with unexpected values.



Discussion:

Resolving patch:
diff --git a/dbt/parser.py b/dbt/parser.py
--- a/dbt/parser.py
+++ b/dbt/parser.py
@@ -452,8 +452,12 @@ def parse_schema_tests(tests, root_project, projects, macros=None):
         if test_yml is None:
             continue
 
+        no_tests_warning = ("* WARNING: No constraints found for model"
+                            " '{}' in file {}\n")
         for model_name, test_spec in test_yml.items():
             if test_spec is None or test_spec.get('constraints') is None:
+                test_path = test.get('original_file_path', '<unknown>')
+                logger.warn(no_tests_warning.format(model_name, test_path))
                 continue
 
             for test_type, configs in test_spec.get('constraints', {}).items():


Test patch:
Repository: dbt-labs/dbt-core

Issue:
Add docs site index.html to MANIFEST.in
## Issue

### Issue description
On `dev/isaasc-asimov`, the `index.html` file is not installed alongside dbt for certain `pip install` invocations. In particular, I saw this trying to install dbt from a github branch via pip. I think there are other types of installations that can cause the `index.html` file to not be picked up.

I believe this can be fixed by adding `*.html` to the [MANIFEST.in](https://github.com/fishtown-analytics/dbt/blob/development/MANIFEST.in) file.


### Steps to reproduce
Run:
```
pip install git+git://github.com/fishtown-analytics/dbt@dev/isaac-asimov.git
```

Then,
```
dbt docs generate
```

Python will throw an error indicating that the `index.html` file was not found


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -22,6 +22,7 @@ def read(fname):
     packages=find_packages(),
     package_data={
         'dbt': [
+            'include/index.html',
             'include/global_project/dbt_project.yml',
             'include/global_project/macros/*.sql',
             'include/global_project/macros/**/*.sql',


Test patch:
Repository: dbt-labs/dbt-core

Issue:
Incompatible dependency requirements: snowflake-connector-python & boto3
## Issue

### Issue description
The latest version of `dbt` (0.10.2) has dependencies which require conflicting versions of `botocore`.

Specifically:
* `boto3` (1.8.3) requires `botocore >=1.11.3, <1.12.0`
* `snowflake-connector-python` (1.6.7) requires `botocore >=1.5.0, <1.11.0`

`pip install dbt` tries to do something like this...
![boto-version-conflict 1](https://user-images.githubusercontent.com/33524269/44790658-be8b1f00-ab97-11e8-9d7a-7079e7a703d8.png)

`dbt 0.10.2` was working fine for us on release, but has just started causing problems. 

`boto3 1.8.0`, released 4 days ago, changed the requirement of `botocore>=1.10.84,<1.11.0` to `botocore>=1.11.0,<1.12.0`. This broke compatibility with `snowflake-connector-python`.  See this [diff](https://github.com/boto/boto3/commit/e25544b1e5256935c874820a8eb2809a8951f0f6#diff-2eeaed663bd0d25b7e608891384b7298). 

### Results
This caused our own library, with `dbt==0.10.2` to fail to run because of the incompatible versions of `botocore`.

### System information
The output of `dbt --version`: `0.10.2`
```
installed version: 0.10.2
   latest version: 0.10.2

Up to date!
```

The operating system you're running on: 
`MacOS High Sierra 10.13.5`

The python version you're using (probably the output of `python --version`)
`Python 3.5.4`

### Steps to reproduce
```
python3 -m virtualenv env  # create clean venv 
source venv/bin/activate  # activate new venv
pip install dbt
```
We then get this warning in the install logs...
```
snowflake-connector-python 1.6.7 has requirement boto3<1.8.0,>=1.4.4, but you'll have boto3 1.8.3 which is incompatible.
snowflake-connector-python 1.6.7 has requirement botocore<1.11.0,>=1.5.0, but you'll have botocore 1.11.3 which is incompatible.
```

### Suggested Solution

We fixed the issue locally by pinning `boto3` to `1.7.84`. This satisfies the requirements of both the latest versions of  `dbt` (0.10.2) and `snowflake-connector-python` (1.6.7).

An alternative would be for `snowflake-connector-python` to require `botocore >=1.11.0`.


Discussion:
Thanks @ianbillett -- we're going to fix this for dbt v0.11.0, due to be released on 9/6. I think our boto3 range will become `>=1.6.23,<1.8.0`.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -52,6 +52,6 @@ def read(fname):
         'google-cloud-bigquery>=1.0.0,<2',
         'agate>=1.6,<2',
         'jsonschema==2.6.0',
-        'boto3>=1.6.23'
+        'boto3>=1.6.23,<1.8.0'
     ]
 )


Test patch:
Repository: dbt-labs/dbt-core

Issue:
Add flag for specifying port for dbt docs serve
## Feature

### Feature description
Include a flag for specifying port number for `dbt docs serve`.

### Who will this benefit?
Port `8080` is a commonly-used port and may already be in use. 



Discussion:

Resolving patch:
diff --git a/dbt/main.py b/dbt/main.py
--- a/dbt/main.py
+++ b/dbt/main.py
@@ -456,6 +456,12 @@ def parse_args(args):
     seed_sub.set_defaults(cls=seed_task.SeedTask, which='seed')
 
     serve_sub = docs_subs.add_parser('serve', parents=[base_subparser])
+    serve_sub.add_argument(
+        '--port',
+        default=8080,
+        type=int,
+        help='Specify the port number for the docs server.'
+    )
     serve_sub.set_defaults(cls=serve_task.ServeTask,
                            which='serve')
 
diff --git a/dbt/task/serve.py b/dbt/task/serve.py
--- a/dbt/task/serve.py
+++ b/dbt/task/serve.py
@@ -14,13 +14,15 @@ class ServeTask(RunnableTask):
     def run(self):
         os.chdir(self.project['target-path'])
 
-        port = 8080
+        port = self.args.port
 
         shutil.copyfile(DOCS_INDEX_FILE_PATH, 'index.html')
 
         logger.info("Serving docs at 0.0.0.0:{}".format(port))
         logger.info(
-            "To access from your browser, navigate to http://localhost:8080.")
+            "To access from your browser, navigate to http://localhost:{}."
+            .format(port)
+        )
         logger.info("Press Ctrl+C to exit.\n\n")
 
         httpd = TCPServer(
@@ -29,7 +31,7 @@ def run(self):
         )
 
         try:
-            webbrowser.open_new_tab('http://127.0.0.1:8080')
+            webbrowser.open_new_tab('http://127.0.0.1:{}'.format(port))
         except webbrowser.Error as e:
             pass
 


Test patch:
Repository: dbt-labs/dbt-core

Issue:
change in agate null handling in 0.11.0
## Issue

### Issue description
The behavior of agate's handling of null values in CSVs changed between 0.10.2 and 0.11.0. Empty cells in csv files are now created as empty strings instead of `null`.

### Results
CSVs with data like this:
```
id,name,age
1,,25
```

are represented as the SQL values `(1, '', 25)`.

### System information
The output of `dbt --version`:
```
0.11.0
```

osx, py27/py37

### Steps to reproduce
There's a CSV that reproduces this error here: https://github.com/fishtown-analytics/dbt-utils/pull/82/files#diff-598f3a3bff26a5e029345bd6a35c4eba


Discussion:

Resolving patch:
diff --git a/dbt/clients/agate_helper.py b/dbt/clients/agate_helper.py
--- a/dbt/clients/agate_helper.py
+++ b/dbt/clients/agate_helper.py
@@ -4,12 +4,12 @@
 DEFAULT_TYPE_TESTER = agate.TypeTester(types=[
     agate.data_types.Boolean(true_values=('true',),
                              false_values=('false',),
-                             null_values=('null',)),
-    agate.data_types.Number(null_values=('null',)),
-    agate.data_types.TimeDelta(null_values=('null',)),
-    agate.data_types.Date(null_values=('null',)),
-    agate.data_types.DateTime(null_values=('null',)),
-    agate.data_types.Text(null_values=('null',))
+                             null_values=('null', '')),
+    agate.data_types.Number(null_values=('null', '')),
+    agate.data_types.TimeDelta(null_values=('null', '')),
+    agate.data_types.Date(null_values=('null', '')),
+    agate.data_types.DateTime(null_values=('null', '')),
+    agate.data_types.Text(null_values=('null', ''))
 ])
 
 


Test patch:
diff --git a/test/integration/005_simple_seed_test/data/seed_actual.csv b/test/integration/005_simple_seed_test/data/seed_actual.csv
--- a/test/integration/005_simple_seed_test/data/seed_actual.csv
+++ b/test/integration/005_simple_seed_test/data/seed_actual.csv
@@ -497,5 +497,5 @@ id,first_name,email,ip_address,birthday
 496,Brenda,bparkerdr@skype.com,63.232.216.86,1974-05-18 05:58:29
 497,Tammy,tmurphyds@constantcontact.com,56.56.37.112,2014-08-05 18:22:25
 498,Larry,lhayesdt@wordpress.com,162.146.13.46,1997-02-26 14:01:53
-499,Evelyn,ethomasdu@hhs.gov,6.241.88.250,2007-09-14 13:03:34
+499,,ethomasdu@hhs.gov,6.241.88.250,2007-09-14 13:03:34
 500,Paula,pshawdv@networksolutions.com,123.27.47.249,2003-10-30 21:19:20
diff --git a/test/integration/005_simple_seed_test/seed.sql b/test/integration/005_simple_seed_test/seed.sql
--- a/test/integration/005_simple_seed_test/seed.sql
+++ b/test/integration/005_simple_seed_test/seed.sql
@@ -508,5 +508,5 @@ VALUES
     (496,'Brenda','bparkerdr@skype.com','63.232.216.86','1974-05-18 05:58:29'),
     (497,'Tammy','tmurphyds@constantcontact.com','56.56.37.112','2014-08-05 18:22:25'),
     (498,'Larry','lhayesdt@wordpress.com','162.146.13.46','1997-02-26 14:01:53'),
-    (499,'Evelyn','ethomasdu@hhs.gov','6.241.88.250','2007-09-14 13:03:34'),
+    (499,NULL,'ethomasdu@hhs.gov','6.241.88.250','2007-09-14 13:03:34'),
     (500,'Paula','pshawdv@networksolutions.com','123.27.47.249','2003-10-30 21:19:20');
Repository: dbt-labs/dbt-core

Issue:
don't validate profile for `dbt clean`
## Feature

### Feature description
This issue https://github.com/fishtown-analytics/dbt/issues/947 skips profile validation for the `dbt deps` command. That behavior should be extended to `dbt clean` as well.

The code change will probably happen around here: https://github.com/fishtown-analytics/dbt/blob/dev/guion-bluford/dbt/main.py#L210-L211



Discussion:

Resolving patch:
diff --git a/dbt/main.py b/dbt/main.py
--- a/dbt/main.py
+++ b/dbt/main.py
@@ -107,7 +107,6 @@ def handle(args):
 
 def handle_and_check(args):
     parsed = parse_args(args)
-
     # this needs to happen after args are parsed so we can determine the
     # correct profiles.yml file
     profile_config = read_config(parsed.profiles_dir)
@@ -207,7 +206,7 @@ def invoke_dbt(parsed):
     cfg = None
 
     try:
-        if parsed.which == 'deps':
+        if parsed.which in {'deps', 'clean'}:
             # deps doesn't need a profile, so don't require one.
             cfg = Project.from_current_directory()
         elif parsed.which != 'debug':
@@ -495,4 +494,10 @@ def parse_args(args):
 
     parsed = p.parse_args(args)
 
+    if not hasattr(parsed, 'which'):
+        # the user did not provide a valid subcommand. trigger the help message
+        # and exit with a error
+        p.print_help()
+        p.exit(1)
+
     return parsed


Test patch:
Repository: dbt-labs/dbt-core

Issue:
Tests that fail with 1 error report "True" instead of "1" for the number of errors
## Issue

### Issue description
Tests that fail with 1 error report "True" instead of "1" for the number of errors. This happens, I think, because we fetch an Agate dataframe, which assumes that the number of failures is a boolean instead of an integer.

### Results
Expected: [FAIL 1]
Received: [Fail True]

### System information
>= 0.11.1

The python version you're using (probably the output of `python --version`)
3.7

### Steps to reproduce

```
-- models/test_model.sql

select null as id

```

```
# schema.yml

version: 2

models:
  - name: test_model:
  - columns:
    name: id
    tests:
      - not_null
```


Discussion:

Resolving patch:
diff --git a/dbt/clients/agate_helper.py b/dbt/clients/agate_helper.py
--- a/dbt/clients/agate_helper.py
+++ b/dbt/clients/agate_helper.py
@@ -2,13 +2,13 @@
 import agate
 
 DEFAULT_TYPE_TESTER = agate.TypeTester(types=[
-    agate.data_types.Boolean(true_values=('true',),
-                             false_values=('false',),
-                             null_values=('null', '')),
     agate.data_types.Number(null_values=('null', '')),
     agate.data_types.TimeDelta(null_values=('null', '')),
     agate.data_types.Date(null_values=('null', '')),
     agate.data_types.DateTime(null_values=('null', '')),
+    agate.data_types.Boolean(true_values=('true',),
+                             false_values=('false',),
+                             null_values=('null', '')),
     agate.data_types.Text(null_values=('null', ''))
 ])
 


Test patch:
Repository: dbt-labs/dbt-core

Issue:
Full BigQuery load errors are neither logged nor displayed for dbt seed
### Issue description
Upon running `dbt seed` for a specific CSV file, the load to BigQuery fails. dbt prints the output as follows:
```
  Error while reading data, error message: CSV table encountered too many errors, giving up. Rows: 1; errors: 1. Please look into the error stream for more details.
```

Unfortunately, this message doesn't provide the root cause of the error (i.e. the issues encountered loading the CSV file). I don't see any additional detail in `dbt.log` beyond what's printed.

I've used the BigQuery Python SDK before for load jobs, and this looks like the output from `job.result()`. However, the job object has an additional attribute called `errors`, which contains the detailed description of the load error. In this past I've handled this with a try/catch block on job creation that raises the full error when a generic API exception is caught. I believe this is what should be logged or surfaced to the user. Happy to attempt a PR if you can point me roughly to where this code lives in dbt!

### System information
The output of `dbt --version`:
```
installed version: 0.11.0
   latest version: 0.11.1
```

The operating system you're running on: Mac OS Mojave

The python version you're using (probably the output of `python --version`) Python 3.4.3


Discussion:
Thanks for the report @joshtemple! 
@drewbanin, would you mind pointing me to where this code exists in dbt? I'd be happy to attempt a fix, I think it would be relatively quick.
@joshtemple this is the python code that loads csvs into bigquery: https://github.com/fishtown-analytics/dbt/blob/dev/guion-bluford/dbt/adapters/bigquery/impl.py#L604-L621

That error message must come from bigquery itself, I don't see it anywhere in dbt.

Resolving patch:
diff --git a/dbt/adapters/bigquery/impl.py b/dbt/adapters/bigquery/impl.py
--- a/dbt/adapters/bigquery/impl.py
+++ b/dbt/adapters/bigquery/impl.py
@@ -278,7 +278,8 @@ def poll_until_job_completes(cls, job, timeout):
             raise dbt.exceptions.RuntimeException("BigQuery Timeout Exceeded")
 
         elif job.error_result:
-            raise job.exception()
+            message = '\n'.join(error['message'].strip() for error in job.errors)
+            raise dbt.exceptions.RuntimeException(message)
 
     def make_date_partitioned_table(self, dataset_name, identifier,
                                     model_name=None):


Test patch: