* We should not modify the original env because it's what is going to be
passed to the Ansible process. This will contain all of the passwords,
unobscured. The safe env is what will get saved into the model.
* Support "name" if given, else use a more reasonable file name for
the playbook file
* Fix an issue where we wouldn't populate the playbooks correctly in
the database
* Force downloading the playbooks every time since we can't tell when
the file might change
* Extend scm credential type to support username and password for
redhat portal accounts
* Update project update playbook to work with remote insights server
* release_3.1.1:
Updating changelog for 3.1.1 release
Fix an issue where notifications might not always be triggered
give a default other than None
Respect the user provided rabbitmq vhost value
Changes to improve the AMI publish process
Add unsupported primary pre-flight check
Removed console
Fixed bug where typing in scm credential when adding/editing project wouldn't work
Encode default search param
update asgi_amqp version
remove uneeded post commit wrapper
all job status change websockets events should happen after the job hits the database
Revert "emit job status over socket after database commit"
emit job status over socket after database commit
requeue websocket messages that don't (yet) have an established user
Force setting the password of the rabbitmq user
rabbit_mq_password required
host event stdout changes
Bump version for 3.1.1 release
1. If the setting isn't in the database, then the specified default is
returned.
2. If the setting IS in the database, then the 'value' field, from the
database, is returned; Unless, the value is null in the database, then
the defined default is returned.
* Take case 1. If the default=None then an AttributeError is raised
* Thus, by setting default='', in case 1. We don't get an AttributeError
because '' will be returned.
* Also note that we don't allow_null=True because then the database
entry could be None. Accessing the setting would raise an AttributeError
in this case. Further, since we set default='' it doesn't matter if null
is in the database.
TL;DR set default=<something_other_than_None>
There's a race between our `ws_connect` and `ws_receive` methods;
it's possible to fall into a scenario where we're handling a legitimate
message *before* django-channels is able to persist the `user_id` into
the channel session. This results in a scenario where a user can open
a browser tab and never receive new websocket messages. In this
scenario, we should just toss the message back into the queue and try
again later (up to a reasonable limit of retries).
