#dev-log

1 messages · Page 35 of 1

regal archBOT
#

If the PGSQL container failed to start, it would keep waiting and outputting retrying as the socket only doesn't error when the port is open, meaning the PGSQL container is fully ready to accept connections.

This also is only done during dev environments, so it's a good reminder that they may have forgotten to up the other container (dunno why they're running docker-compose site in that case though), or they severely broke something.

ebon magnetBOT
#

Build 20190928.6 succeeded

Requested by

GitHub

Duration

00:02:00

Build pipeline

Site

oak estuaryBOT
oak estuaryBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20190928.7 succeeded

Requested by

GitHub

Duration

00:01:58

Build pipeline

Site

regal archBOT
#

Any idea why the pipeline is failing on typed_ast? It's definitely in Pipefile.lock

https://paste.pythondiscord.com/ebelenecex.txt

Manylinux wheels don't work on muslc-based distros such as Alpine. Therefore, it tries to build from source but cannot because gcc is not installed. Could be fixed but the images will probably be moved to python slim images like the other repos, which I think is Debian.

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20190929.1 succeeded

Requested by

GitHub

Duration

00:01:55

Build pipeline

Site

regal archBOT
#
[python-discord/site] branch deleted: new\-managepy
ebon magnetBOT
#

Build 20190929.2 failed

Requested by

Leon Sandøy

Duration

00:02:18

Build pipeline

Site

regal archBOT
north knotBOT
ebon magnetBOT
#

Build 20190929.3 succeeded

Requested by

GitHub

Duration

00:03:45

Build pipeline

Site

regal archBOT
regal archBOT
#

Now that https://github.com/python-discord/site/pull/265 has been merged, the bot project can utilise the better entry point, remove a couple of redundant sections in the compose, and add the bot service to compose for local development.

BOT_TOKEN is pulled directly from the .env still, just the same as when launching via pipenv locally.

BOT_API_KEY uses the default key that site now generates automatically.

Setting up the hosts file is now entirely optional, as the API...

ebon magnetBOT
#

Build 20190930.1 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
ebon magnetBOT
#

Build 20190930.1 succeeded

Requested by

GitHub

Duration

00:02:09

Build pipeline

Site

regal archBOT
#
[python-discord/site] branch deleted: decoupling\-warnings\-and\-notes
north knotBOT
ebon magnetBOT
#

Build 20190930.2 succeeded

Requested by

GitHub

Duration

00:04:00

Build pipeline

Site

regal archBOT
#
[python-discord/bot] branch deleted: new\-development\-workflow
north knotBOT
ebon magnetBOT
#

Build 20190930.2 succeeded

Requested by

GitHub

Duration

00:03:46

Build pipeline

Bot

oak estuaryBOT
regal archBOT
north knotBOT
ebon magnetBOT
#

Build 20190930.3 succeeded

Requested by

Leon Sandøy

Duration

00:04:13

Build pipeline

Site

regal archBOT
#
[python-discord/site] New branch created: fix\_toc\_header
ebon magnetBOT
#

Build 20190930.4 succeeded

Requested by

GitHub

Duration

00:02:06

Build pipeline

Site

regal archBOT
regal archBOT
#
[python-discord/site] New branch created: migrate\-nominations\-to\-nominations\-models
regal archBOT
regal archBOT
#

Before the migration to Django, we stored information on a nomination, like the reason and end_reason, as note infractions with a special prefix in the infractions table. We've since decided that nominations shouldn't be categorized under infractions and have create a separate model for nominations in the new Django back-end. This PR migrates the historical nomination data still stored in the infractions table to the new nominations table by using a data migration.

The data migration t...

ebon magnetBOT
#

Build 20190930.5 succeeded

Requested by

GitHub

Duration

00:02:17

Build pipeline

Site

regal archBOT
#

Right now, there's nothing discouraging us from having these off-topic names added to the list:

kosaa
kosaaa
kosaaaa

Although that would be nice, we should have the bot by default return that an off-topic name is too similar to an existing one and thus wasn't added.

Implementation details

  • Show the similar name and the similarity
  • Don't add the name if it is >X% similar to an existing one
  • Add a !otn forceadd to bypass the check
regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20190930.4 failed

Requested by

GitHub

Duration

00:01:26

Build pipeline

Bot

ebon magnetBOT
#

Build 20190930.5 failed

Requested by

GitHub

Duration

00:01:18

Build pipeline

Bot

regal archBOT
regal archBOT
regal archBOT
#
[python-discord/site] New branch created: navbar\-add\-contributing\-link
ebon magnetBOT
#

Build 20190930.6 succeeded

Requested by

GitHub

Duration

00:02:04

Build pipeline

Site

regal archBOT
#

I've looked, but I haven't found a built-in way to do this with DRF. Since a lot of the serializers already have some sort of custom validation function, I think the easiest way forward is to add a decorator that compares the keys of the received data with the fields specified in the model before it runs the regular validate method of the serialized.

I'll have a look to see if I can come up with something that doesn't look too bad.

regal archBOT
#

A minor usability that allows !docs Python in place of !docs get Python.

This seems to have been the intention of the old code, however invoke doesn't pass the arguments forward by default, so the UX was confusing.

AFAICT this could be written ctx.invoke(self.get_command, symbol), however this would only serve to complicate and slow things down. Tell me if it provides some utility, and I'll change it

ebon magnetBOT
#

Build 20190930.6 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

north knotBOT
ebon magnetBOT
#

Build 20190930.7 succeeded

Requested by

GitHub

Duration

00:03:48

Build pipeline

Site

regal archBOT
regal archBOT
#

This allows us to do some backend QoL stuff:

  • Override add_cog() so that it logs the loading of cogs
  • IDEs will recognise additional attributes, such as the API client
  • Override load_extensions() so that it automatically prepends bot.cogs to the name given

And there's maybe more stuff I'm forgetting.

regal archBOT
#
[python-discord/bot] New branch created: update\-contrib\-doc
#
[python-discord/site] New branch created: update\-contrib\-doc
#
[python-discord/site] branch deleted: update\-contrib\-doc
ebon magnetBOT
#

Build 20191001.1 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

#

Build 20191001.1 succeeded

Requested by

GitHub

Duration

00:01:57

Build pipeline

Site

regal archBOT
#
[python-discord/site] branch deleted: navbar\-add\-contributing\-link
north knotBOT
ebon magnetBOT
#

Build 20191001.2 succeeded

Requested by

GitHub

Duration

00:03:44

Build pipeline

Site

north knotBOT
ebon magnetBOT
#

Build 20191001.3 succeeded

Requested by

GitHub

Duration

00:03:55

Build pipeline

Site

regal archBOT
#

Remove executable or potentially executable files that may be malicious (malware, spam, zip bombs, etc.).

Per Lemon: "Staff meeting consensus is that we can start simple by whitelisting certain extensions and deleting everything else. If people try to get around this with malicious hybrid filetypes or whatever, we will discuss maybe using ClamAV to scan files, but for now, we'll keep it simple. This should just be another filter, like mentionspam."

Org issue: https://github.com/python-...

regal archBOT
ebon magnetBOT
#

Build 20191001.2 failed

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.3 succeeded

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.4 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

regal archBOT
#

Only a single unmute task per user is pending of which is always the longest active mute.

I agree but it's somewhat tricky unless the same scheduler instance is used. Well, the database can be queried for active infractions but technically there's nothing enforcing that a scheduled infraction is also present and active in the database. It's a bit of a mess I suppose.

Don't allow weirdness such as new mutes that are meant to end earlier than existing ones.

On one hand, infractions...

regal archBOT
regal archBOT
#

On one hand, infractions durations can already be edited with a separate command. On the other hand, it may be more convenient to have durations accumulate in the sense that if it did error out, then it'd be an extra step to run merely a different command with similar parameters. However, it would not be convenient (quite the opposite) if the actor did not wish for the times to accumulate and would have rather had their second infraction attempt invalidated. Therefore, I am leaning towards ...

north knotBOT
#

Postgres backup completed!

regal archBOT
#

So, I think the shimmer effect itself is pretty good, but there are a couple of things I think we should clean up before we use this:

  • It would be great if the shimmer would travel left to right, across the entire logo, sort of like this. Currently it's sort of traveling in a weird reverse S shape starting bottom right and ending top right, and that looks pretty nonstandard and a bit weird.
  • Like our othe...
#

Like our other icon animations, this animation will need breathing room at the end of the cycle, or it will animate constantly on mobile. A rule of thumb we've used before is to put the animation at the beginning, then have 5ish seconds of no animation, and then end the loop.

It's also a good idea to make sure the very first frame of the animation is static, since that frame will be used when the logo is displayed statically (e.g., when the icon is not hovered on desktop; when the user i...

regal archBOT
#
[python-discord/bot] New branch created: ISODate\-converter
#

This pull requests adds a converter that automatically parses ISO-formatted datetime strings and returns a datetime.datetime object. It uses dateutil.parser.isoparse to do the heavy lifting and therefore supports the same formats.

In addition, I've added tests that "guarantee" that certain standard formats will be accepted and added these "guaranteed" formats to the docstring of the ISODate.convert meth...

ebon magnetBOT
#

Build 20191001.5 failed

Requested by

GitHub

Duration

00:01:21

Build pipeline

Bot

regal archBOT
#

Currently, the !tag edit subcommand is just an alias of !tag set. This means that if we try to edit an existing tag, the bot will use the POST http method to communicate with the API. Since we're not posting a new tag, but editing an existing entry, the API will reject this request.

Instead of using POST, we should be using PATCH, since we're only partially updating the entry in the database. (We're editing the embed field, not the name field.)

regal archBOT
#
[python-discord/bot] New branch created: fix\-tags\-edit\-command
#

This pull request makes sure that we're using the PATCH method to update tags, instead of the POST method.

The problem was that the !tags edit command was an alias of !tags set, which uses the POST method to post new tags to the API. However, when a tag with a given name already exists, the API will refuse a POST request in an attempt to update it; we need to use the PATCH method to the bot/tags/{tag_name} endpoint instead.

To fix this, I've created a separate subcommand, `!tags ...

ebon magnetBOT
#

Build 20191001.6 succeeded

Requested by

GitHub

Duration

00:02:02

Build pipeline

Bot

regal archBOT
#

We recently removed the reason from the infraction confirmation message. The reason was that if the infraction was manually invoked, both the message that contained the command and the confirmation message would contain the reason, which would take up a lot of vertical space when the reason had some length.

However, when an infraction was invoked automatically (e.g., by the AntiSpam cog), having the reason in the infraction notification actually provided context to what's going on. T...

regal archBOT
#

This is further to the discussions in #meta and the 2019 Hacktoberfest channel, and https://github.com/python-discord/site/issues/210

It would be excellent if Snekbox supported a kind of "session mode". Such a mode would allow one to run a persistent Python process in order to serve up a Python REPL or other long-running interactive application. There are some hang-ups to this approach, however..

Shared Processes

Having Python processes that are shared between multiple session...

regal archBOT
#

On @lemonsaurus' advice, I decided to look into how repl.it might meet our needs.

Suitability

I think repl.it would be able to handily meet all of our needs - it supports once-time program execution, as well as websockets for interactive sessions. It appears to have a comprehensive API too, but I'm unable to get much info on that (see below).

API

While the API appears to be comprehensive from what I can find, it's stated on the [main API...

regal archBOT
ebon magnetBOT
#

Build 20191001.7 succeeded

Requested by

GitHub

Duration

00:01:51

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.8 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: update\-contrib\-doc
north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191001.9 succeeded

Requested by

GitHub

Duration

00:03:34

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.11 failed

Requested by

GitHub

Duration

00:01:22

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.12 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.13 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.14 failed

Requested by

GitHub

Duration

00:01:25

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.15 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

regal archBOT
regal archBOT
regal archBOT
#
[python-discord/site] New branch created: tizzysaurus\_landing\_page\_text
ebon magnetBOT
#

Build 20191001.4 succeeded

Requested by

GitHub

Duration

00:01:55

Build pipeline

Site

regal archBOT
#

What "packages instead of modules" means is that the extension is an __init__.py of a sub-package i.e. the setup() function is in __init__.py (this is what watchchannels is doing right now).

The culprit is this code https://github.com/python-discord/bot/blob/341fb5200acbf24ab1220339b6ce7cf6816561a5/bot/cogs/cogs.py#L28

It's just an overcomplicated and inaccurate way to accomplish this, especially since the [Bot.extensions](https://discordpy.readthedocs.io/en/latest/ext/comman...

regal archBOT
#
[python-discord/bot] New branch created: separate\_tools\_and\_resources
ebon magnetBOT
#

Build 20191001.16 failed

Requested by

GitHub

Duration

00:01:19

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.17 succeeded

Requested by

GitHub

Duration

00:01:46

Build pipeline

Bot

regal archBOT
#

Added checks for response.status and response.content_type for fetch_posts() to validate the response from self.bot.http_session.get(). Also added retries in case a bad response is received.

It's been tested to verify that the !reddit top (and similar) commands still work, and I simulated some retry behavior by specifying intentionally bad routes. Please let me know what changes you'd like to see!

ebon magnetBOT
#

Build 20191001.18 succeeded

Requested by

GitHub

Duration

00:01:33

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191001.19 succeeded

Requested by

GitHub

Duration

00:01:33

Build pipeline

Bot

regal archBOT
#

Thanks for the well thought out response. I like your proposed API changes. I believe it'll be a lot simpler to add those restrictions in the API then have convoluted checks client-side. And, in general, not needing any logic to account for multiple active infractions (relevant for unmute/unban currently) also reduces client-side code complexity.

One concern I have about making notes and warnings inactive always is that it makes infraction queries (once that is implemented, it's already an...

regal archBOT
ebon magnetBOT
#

Build 20191002.1 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.2 succeeded

Requested by

GitHub

Duration

00:01:33

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.3 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.4 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: separate\_tools\_and\_resources
north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191002.5 succeeded

Requested by

GitHub

Duration

00:03:48

Build pipeline

Bot

#

Build 20191002.6 succeeded

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: fix\-tags\-edit\-command
north knotBOT
ebon magnetBOT
#

Build 20191002.7 succeeded

Requested by

GitHub

Duration

00:03:27

Build pipeline

Bot

oak estuaryBOT
regal archBOT
ebon magnetBOT
#

Build 20191002.8 succeeded

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
north knotBOT
ebon magnetBOT
#

Build 20191002.9 succeeded

Requested by

GitHub

Duration

00:03:24

Build pipeline

Bot

oak estuaryBOT
regal archBOT
#

The unload_cog method of the WatchChannel ABC has a small bug in it. If you try to reload or unload the cog while the message consumption task has not yet started, it will fail because the bot._consume_task attribute will still be assigned to None:

https://github.com/python-discord/bot/blob/cff9cabfee014e6207e156ee69e8b326ece55800/bot/cogs/watchchannels/watchchannel.py#L335-L339

This will lead to the following exception, which also prevents us from reloading the extensions that ...

#
[python-discord/bot] New branch created: fix\-watchchannels\-unload\-cog\-bug
#

There was small bug in the cog_unload method of the WatchChannel ABC. The reason is that it tries to check if the Task assigned to self._consume_task is done by accessing its done method without ensuring that self._consume_task has been assigned to an actual Task yet.

My solution is to change the if condition to this:

if self._consume_task and not self._consume_task.done():

This pull request closes #482

ebon magnetBOT
#

Build 20191002.10 succeeded

Requested by

GitHub

Duration

00:01:33

Build pipeline

Bot

regal archBOT
#

How should time zones be dealt with? There is some other code that expects timezone-naïve datetimes (for example, utils.time.wait_until) so we could run into trouble with that. Perhaps the better solution would be to make everything else timezone-aware too.

This converter does not force tzinfo at the moment. If you feed it a datetime string without a timezone specifier, it will return a naive datetime.datetime, if you feed it something that does specify a timezone, it does return a...

#

This converter does not force tzinfo at the moment.

Yeah, I was aware it depends on the input. Inputs that result in timezone-aware datetimes could be problematic.

Do you think we should restrict this to one or the other at the level of the converter?

Well, maybe. But as I said, perhaps a more proper solution would be to make other things work with timezone-aware datetimes. It'd be nice to support timezones in user inputs but right now it isn't an important feature anywhere (but ...

ebon magnetBOT
#

Build 20191002.11 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.12 succeeded

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
#
[python-discord/bot] New branch created: extensions\-cog
ebon magnetBOT
#

Build 20191002.13 succeeded

Requested by

GitHub

Duration

00:01:30

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.14 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
#

Okay, I've looked into the option of using timezone-aware datetime objects everywhere and I like the idea. However, I think it is a much broader and larger issue than this converter and I don't think we should tack such a change on this pull request. That's why my proposal is to make sure that this converter returns the UTC-time stored in timezone-unaware datetime objects for now.

The reason is that discord.py returns unaware datetime objects for datetime related attributes an...

ebon magnetBOT
#

Build 20191002.15 failed

Requested by

GitHub

Duration

00:01:19

Build pipeline

Bot

ebon magnetBOT
#

Build 20191002.16 failed

Requested by

GitHub

Duration

00:01:18

Build pipeline

Bot

#

Build 20191002.17 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.18 succeeded

Requested by

GitHub

Duration

00:01:43

Build pipeline

Bot

regal archBOT
#

Okay, so word back from repl.it is:

They are currently working on opening up their API, and this will be out soon:tm: .

Meanwhile, if we're in a hurry, we can port this npm package: https://www.npmjs.com/package/@replit/crosis

They warn that this might not be that easy, and have sent over the following docs that might be of use:
https://multiplayer-blog-docs.turbio.repl.co/protov2
https://multiplayer-blog-docs.turbio.repl.co/services

They've also provided a way of generating a t...

#
[python-discord/bot] New branch created: off\-topic\-check
regal archBOT
#

Hmm, I think you might be right on waiting. That goval protocol seems to be too complex to implement ourselves for this specific use-case - even though it seems like they've written a protobuf so it shouldn't be too difficult to port, it seems like a lot of maintenance overhead.

If they're working on it already, might as well let them instead of doing it ourselves and then dumping that code later, right?

regal archBOT
#

Hey @RohanJnr,

Like mentioned in the issue, the standard approach does not work consistently for our bot, as it does not always return the right starting line and/or code length. I have not looked into why it's happening, although it may be because of decorators passing the function around.

As an example, issuing !source help sends me to https://github.com/python-discord/bot/blob/master/bot/cogs/help.py#L108-L140, which obviously not where we want to end up. Help may be the only on...

regal archBOT
#

Hey @RohanJnr,

Like mentioned in the issue, the standard approach does not work consistently for our bot, as it does not always return the right starting line and/or code length. I have not looked into why it's happening, although it may be because of decorators passing the function around.

As an example, issuing !source help sends me to https://github.com/python-discord/bot/blob/master/bot/cogs/help.py#L108-L140, which is obviously not where we want to end up. Help may be...

ebon magnetBOT
#

Build 20191002.19 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
#
[python-discord/branding] New branch created: hacktober\-animated\-neon\-flicker\-icon
#
[python-discord/branding] New branch created: hacktoberfest\-gif\-guild\-icon
#
[python-discord/branding] branch deleted: hacktoberfest\-gif\-guild\-icon
ebon magnetBOT
#

Build 20191002.20 succeeded

Requested by

GitHub

Duration

00:01:33

Build pipeline

Bot

#

Build 20191002.21 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.23 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

#

Build 20191002.22 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.24 succeeded

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.25 succeeded

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
#

That reminds me actually, I was going to suggest also to move the category into scope of the class instead, as it's not instance specific.

One approach regarding the description is the instead find the first instance of another attribute category_description across the cogs, so you could define it once anywhere and the rest won't need to.

description=cog.category_description if hasattr(cog, "category_description") else cog.description
regal archBOT
#

The reason and the warning type were switched here

        infraction = await utils.post_infraction(ctx, user,  "warning", reason)

!warn @David Bowie Kitties! led to:

 Oct 02 21:22:29 Bot: |         bot.cogs.moderation.utils |    ERROR | An unexpected ResponseCodeError occurred while adding an infraction:
Traceback (most recent call last):
  File "/home/sebastiaan/pydis/repositories/djangobot/bot/cogs/moderation/utils.py", line 71, in post_infraction
    r...
oak estuaryBOT
regal archBOT
#

Currently, the database accepts multiple active infractions of the same type for a single user. We're currently in the process of making sure the client will try to prevent this from happening, but it's a good idea to implement validation at the server side as well.

My idea is to:

  • Write a data migration that "cleans" the database of this kind of entries.
  • Add a UniqueTogetherValidator to prevent the API from accepting a secondary active infraction of the same type.

Ideally, this va...

regal archBOT
#
[python-discord/bot] New branch created: mute\-fix
ebon magnetBOT
#

Build 20191002.26 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: fix\-watchchannels\-unload\-cog\-bug
ebon magnetBOT
#

Build 20191002.27 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191002.28 succeeded

Requested by

GitHub

Duration

00:03:29

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191002.29 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: mute\-fix
north knotBOT
ebon magnetBOT
#

Build 20191002.30 succeeded

Requested by

Joseph Banks

Duration

00:03:22

Build pipeline

Bot

oak estuaryBOT
regal archBOT
regal archBOT
#
[python-discord/django-simple-bulma] New branch created: update\-dependency\-pinning
ebon magnetBOT
#

Build 20191003.1 succeeded

Requested by

GitHub

Duration

00:01:48

Build pipeline

Django Simple Bulma

regal archBOT
ebon magnetBOT
#

Build 20191003.2 succeeded

Requested by

GitHub

Duration

00:01:44

Build pipeline

Django Simple Bulma

regal archBOT
#
[python-discord/django-crispy-bulma] New branch created: update\-dependency\-pinning
ebon magnetBOT
#

Build 20191003.1 succeeded

Requested by

GitHub

Duration

00:01:54

Build pipeline

Django Crispy Bulma

regal archBOT
ebon magnetBOT
#

Build 20191003.1 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

ebon magnetBOT
#

Build 20191003.2 succeeded

Requested by

GitHub

Duration

00:01:42

Build pipeline

Bot

regal archBOT
regal archBOT
regal archBOT
#

I'm working on resolving the conflict caused by #486. I want to just replace all the redundant infraction deactivation code it brings with a call to self.deactivate_infraction(). However, using this method has two problems, both caused by the role failing to be removed (which could be solved by re-adding the role before calling the method but that seems redundant):

  1. The mod log will show as "failed". There is already an parameter to disable sending the mod log. However, some mod log pr...
ebon magnetBOT
#

Build 20191003.3 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
regal archBOT
#

I'm working on resolving the conflict caused by #486. I want to just replace all the redundant infraction deactivation code it brings with a call to self.deactivate_infraction(). However, using this method has two problems, both caused by the role failing to be removed (which could be solved by re-adding the role before calling the method but that seems redundant):

1. The mod log will show as "failed". There is already an parameter to disable sending the mod log. However, some ...
regal archBOT
ebon magnetBOT
#

Build 20191003.4 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

regal archBOT
#

I'm very ambivalent about this idea. I don't think it really affords that much convenience over our current system where people (helpers, regular members, whoever) just pings @Moderators to bring us to the channel where trouble is afoot. It seems kind of like a Stack Overflowism. It'd probably be fun to write and I don't really see much harm in it, but personally I wouldn't be offended if we just closed this issue, either.

#

Something similar to that, yes, but this issue is going to be difficult for you to work on because we don't have any way for you to log in and be able to edit these pages (only Core Devs have access so far). These are wiki pages, not static pages.

There's some more information about how these pages should be set up, but, it's on a private repo that's used by staff so the URL will 404 for you.

The relevant issue can be found here: https://github.com/python-discord/organisation/issues/66
...

regal archBOT
#

I was writing a very wordy reply, but I decided to ditch in favor of a shorter one.

I'm not sure about this idea for a number of reasons:

  • We currently actively "promote" reports with mentions under the motto "It's better to have one ping too many than one too few". Unless our moderators indicate they'd rather see far fewer pings, I don't think we should look into decreasing pings with the risk of missing reports. This means I wouldn't introduce this system for the goal of reducing pi...
regal archBOT
regal archBOT
#
[python-discord/site] New branch created: \#201\-django\-allauth
ebon magnetBOT
#

Build 20191003.1 failed

Requested by

GitHub

Duration

00:01:40

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191003.2 succeeded

Requested by

GitHub

Duration

00:02:02

Build pipeline

Site

ebon magnetBOT
#

Build 20191003.5 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
#

@SebastiaanZ

One option is to split this method that does two things, removing the role from the member and requesting the API to mark an entry in the database as inactive, into two methods that do one thing, optionally having the remove_role method call the mark_inactive (just filler names; I'd say you're activity is just fine) if we think that's a combination we always want to have.

If the mute was split, it'd be something like this:

async def pardon_mute(self, ctx: Cont...
regal archBOT
#

I don't think I understand what you mean. From the fix you were referencing, I was under the impression we were talking about calling deactivate_infraction in the on_member_join event after finding an active mute infraction for the user in the database that has since expired.

If so, that means the user does not have the mute role, since they just joined the server. By splitting up the deactivate_infraction method into two methods, remove_role (related to the user's state on Discord...

ebon magnetBOT
#

Build 20191003.6 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

regal archBOT
#

I think you mean was not a member, but that make sense so I agree. Now I am wondering if we even want to show the expiration as failed in the mod log when the user already doesn't have the muted role or they don't have an active ban. Thinking about it now, it's actually technically still a success in the sense that they indeed are no longer affected by the infraction, which was the goal of the function.

native joltBOT
#

Description
It would be nice if flake8-annotations could tell the difference between a callable returning None or using return for flow control, and functions that actually return a value.

Rationale/Use Case
I was surprised to see this behaviour at all at first, although it makes sense now that it's been explained to me.

  • Having a separate error code and message specifically mentioning None returns helps to clarify that this is an intentional part of the project's code styl...
native joltBOT
#

It's certainly an interesting concept but I don't think this is feasible from within flake8's framework for anything but trivial examples.

The case of cross-file function calls is particularly problematic since flake8 operates on a per-file basis and provides no mechanism to persist information globally for the package being linted, so there is no deterministic way for this plugin to tell if a foo() in return foo() returns anything or not. I'm not comfortable with making the assumption...

#

That's an interesting point, and I'm not sure if there could be a decent solution to that one - static code analysis tools generally are expected to operate on single files regardless.

I personally feel like assuming the foo() in return foo() doesn't return None is a fairly safe assumption however, as the use-cases for return being used in this manner while foo() only ever returns a None value are extremely limited - but you probably have a better idea than me of the impact of ...

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191003.7 succeeded

Requested by

GitHub

Duration

00:01:41

Build pipeline

Bot

regal archBOT
regal archBOT
#
[python-discord/site] New branch created: flake8\-exclude\-fix
ebon magnetBOT
#

Build 20191003.3 succeeded

Requested by

GitHub

Duration

00:01:53

Build pipeline

Site

ebon magnetBOT
#

Build 20191003.8 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

#

Build 20191003.9 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191003.10 succeeded

Requested by

GitHub

Duration

00:01:33

Build pipeline

Bot

regal archBOT
#

Double active infractions may still occur for now. The code for the PR is done, the migrations file as well, but it will be stalled until python-discord/site#269 is resolved, since that PR also adds a migration file (and is actually far more critical). (We can't merge them independently because migration files have a single, explicit parent file mentioned in their body.)

I was debating with myself not to include the data migration and open a PR later, to prevent the conflict and not stall ...

regal archBOT
ebon magnetBOT
#

Build 20191003.4 failed

Requested by

GitHub

Duration

00:01:52

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191003.11 succeeded

Requested by

GitHub

Duration

00:01:31

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191003.13 succeeded

Requested by

GitHub

Duration

00:01:33

Build pipeline

Bot

regal archBOT
#

83f890e Add checks for valid response and retries to fe... - bendiller
2bc08cc Add logging for invalid response (after all ret... - bendiller
0b59585 Add sleep(3) between retries, with bot indicati... - bendiller
241f74c Move asyncio.sleep() to avoid disturbing functi... - bendiller
df4906c Improve readability - bendiller

north knotBOT
ebon magnetBOT
#

Build 20191003.14 succeeded

Requested by

GitHub

Duration

00:03:24

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191004.1 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191004.2 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

regal archBOT
#

The fix works as expected, but I'm not entirely sure if that tells us that it's working. The problem is that I can't replicate the difference in behavior, as precommit excludes the migration files with both versions of .flake8 in place. That makes me think that the behavior may be platform-dependent.

That said, if both versions work for some and the new version seems to work for everyone, the new version is definitely an improvement.

regal archBOT
regal archBOT
regal archBOT
#
[python-discord/site] branch deleted: flake8\-exclude\-fix
north knotBOT
ebon magnetBOT
#

Build 20191004.1 succeeded

Requested by

GitHub

Duration

00:03:57

Build pipeline

Site

regal archBOT
regal archBOT
#

I'd prefer to avoid standard logins and rely on both account creation and logins being reliant on oauth.

The django admin login should use this system, but is there a way to make sure that there's a way to still use the generic admin account as a backup still, just in case something goes wrong with oauth.

I don't know enough about the django login system to be able to comment on the last point.

#

The django admin login should use this system, but is there a way to make sure that there's a way to still use the generic admin account as a backup still, just in case something goes wrong with oauth.

I don't know enough about the django login system to be able to comment on the
last point.

When you talk about the Django auth system, you basically need to think about how access in general works. Django provides a login system with its own users, permissions and permissions grou...

regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191004.2 failed

Requested by

GitHub

Duration

00:01:51

Build pipeline

Site

#

Build 20191004.3 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191004.4 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

regal archBOT
regal archBOT
#
[python-discord/bot] New branch created: bb\-previous\-reason
ebon magnetBOT
#

Build 20191004.5 succeeded

Requested by

GitHub

Duration

00:01:31

Build pipeline

Bot

regal archBOT
#

Seems like a fine start as-is

Should the total include the just-added infraction or exclude it? It currently excludes it.

I'd say exclude, with a tweak of the verbiage to something like n previous watches

As an aside, these commands are nearly identical in implementation between the two submodules. While perfectly functional, this seems like something that could be refactored into something more generic. From a brief scan, this seems to be the case for much of the watchchannel lo...

#

As an aside, these commands are nearly identical in implementation between the two submodules. While perfectly functional, this seems like something that could be refactored into something more generic. From a brief scan, this seems to be the case for much of the watchchannel logic in general, so maybe this is better investigated within the scope of a different PR.

I was fooled into thinking that. While some of the checks at the start certainly could be refactored, the nominations actual...

ebon magnetBOT
#

Build 20191004.6 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
regal archBOT
#

Currently, all the roles in the community are unmentionable. This is in order to prevent spam. Before we made this change, people would occasionally come into the community and just mentionspam all the role mentions.

The problem with this is that we sometimes need to mention a role. For example, we mention the @Announcements role every time we make an announcement. We all desperately wish Discord would allow us to set mention permissions so that only certain roles were allowed to mention...

regal archBOT
#
[python-discord/bot] New branch created: doc\-fix
#

Fixes #477

What was causing this:

  • The symbol discord returns the URL https://discordpy.readthedocs.io/en/latest/discord.html
  • The URL has no #symbol_name at the end, so splitting by # and getting the last element returns the entire URL
    symbol_id = url.split('#')[-1]
    
  • Searching for an element in the HTML which has an ID equal to the entire URL obviously fails, hence the returned element is None
  • Thus accessing the strings attribute of None...
ebon magnetBOT
#

Build 20191004.7 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191004.8 succeeded

Requested by

GitHub

Duration

00:01:28

Build pipeline

Bot

regal archBOT
#

20da075 Add converter for ISO-formatted datetime strings - SebastiaanZ
3bb8207 Remove surplus quotation mark in class docstring - SebastiaanZ
5f81b80 Apply docstring review suggestion - SebastiaanZ
333d5e6 Remove angle brackets from ISODateTime docstring - SebastiaanZ
a8b6002 Make ISODateTime return tz-unaware datetime - SebastiaanZ

#
[python-discord/bot] branch deleted: ISODate\-converter
north knotBOT
ebon magnetBOT
#

Build 20191004.9 succeeded

Requested by

GitHub

Duration

00:03:23

Build pipeline

Bot

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191004.3 failed

Requested by

GitHub

Duration

00:02:08

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191004.4 succeeded

Requested by

GitHub

Duration

00:02:05

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191004.5 succeeded

Requested by

GitHub

Duration

00:02:04

Build pipeline

Site

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191005.1 succeeded

Requested by

GitHub

Duration

00:01:30

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: bb\-previous\-reason
ebon magnetBOT
#

Build 20191005.3 succeeded

Requested by

GitHub

Duration

00:01:30

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: add\-role\-info\-command
north knotBOT
ebon magnetBOT
#

Build 20191005.2 succeeded

Requested by

GitHub

Duration

00:03:30

Build pipeline

Bot

oak estuaryBOT
ebon magnetBOT
#

Build 20191005.4 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191005.5 succeeded

Requested by

GitHub

Duration

00:03:14

Build pipeline

Bot

ebon magnetBOT
#

Build 20191005.6 failed

Requested by

GitHub

Duration

00:01:18

Build pipeline

Bot

regal archBOT
#

Can you please add an informative description to the PR.

Linting has also failed due to a number of issues; please ensure you have the precommit hook installed with pipenv run precommit so you will be prevented from committing when linting fails.

To see locally your linting results use pipenv run lint.

Your commit history has a PR reference for your own fork at the beginning, can you please rebase to remove that. I'd suggest also fixing your linting issues at the same time to pre...

#

Discussion on Discord alleviated my concerns about this being "hacky", especially if the attribute is changed from an instance attribute to a class attribute. Additionally, the support for categories will be documented in the HelpSession class.

Regarding the description, I agree making it an attribute of the cog is a good idea.

If categories are going to be used more frequently in the code base, a more "structured" and documented approach could be considered. For now, with only one ca...

regal archBOT
ebon magnetBOT
#

Build 20191005.7 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

regal archBOT
#

In addition, some nominations may not have received an end_reason when ending the nomination; these nominations will appear as active incorrectly.

Wouldn't that make all end reasons be skewed in the migration? As in, the wrong end infraction would be used to make a nomination inactive. Or is this not the case because the users would have to match? If so, then it would be really be an edge case for something like that to cause a skew, right?

north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191005.8 failed

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
#

okay, so to address some of these questions:

  • Nobody should be able to sign in using usernames and passwords, except a sort of superadmin account which we can store in the keepass. This account should only be able to sign in via /admin, although you don't have to actually restrict this, we're just not gonna attach any social to it.
  • Everybody else must sign in using a Discord account. Don't allow any other kind of social.
  • The goal should be for us to match their Discord sign-in to ou...
ebon magnetBOT
#

Build 20191005.9 succeeded

Requested by

GitHub

Duration

00:01:28

Build pipeline

Bot

#

Build 20191005.10 failed

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191005.11 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

#

Build 20191005.2 succeeded

Requested by

GitHub

Duration

00:02:02

Build pipeline

Site

regal archBOT
#

The <p> tags are meant to be for paragraphs. You have paragraphs present but instead use the <p> tag as a content wrap and split paragraphs with <br/><br/>.

I'd suggest using the following structure:

          <p>
            We're a large community focused around the Python programming language.
            We believe anyone can learn to code, and are very dedicated to helping
            novice developers take their first steps into the world of programming. We also...
#

Hi @kraktus, and thanks for the PR!

I'm going to mark this PR as invalid and close it. The reason I'm doing this is because, in the spirit of Hacktoberfest, we're not accepting oneliners that don't have an open issue for them at this time.

However; that doesn't mean this change isn't welcome. I would suggest you add this change to the PR you open when you solve the issue you're assigned to https://github.com/python-discord/bot/issues/320. A famous programming book called The Pragm...

#

Yeah exactly. You can make a kaizen commit in an otherwise unrelated PR, just make sure it gets its own commit and that you explain in detail in the commit message what this commit is for.

Here's some good information on how we'd like the commit messages to look:
https://thoughtbot.com/blog/5-useful-tips-for-a-better-commit-message
http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html

ebon magnetBOT
#

Build 20191005.12 succeeded

Requested by

GitHub

Duration

00:01:30

Build pipeline

Bot

regal archBOT
#

Would this situation arise from this?

In addition, some nominations may not have received an end_reason when ending the nomination; these nominations will appear as active incorrectly.

No, it does not arise from it. Currently, if someone has received a first nomination that was ended before we recorded "end reasons" and then received a new nomination, the new nomination would be rejected, since someone can't have two active nominations at the same time. If we'd then observe an "...

#

In addition, some nominations may not have received an end_reason when ending the nomination

Wouldn't that make all end reasons be skewed in the migration? As in, the wrong end infraction would be used to make a nomination inactive. Or is this not the case because the users would have to match? If so, then it would be really be an edge case for something like that to cause a skew, right?

No, all nominations are user specific, so skews may occur, but only within the same individu...

regal archBOT
#

This doesn't match the current project code style:

  • we don't use hanging indents like you're using, instead choosing to drop a line and indent normally.
  • we use double quotation marks for strings unless avoiding escapes.
  • args are usually kept in order of original signature.
  • we have a line length of 120 available. Avoid splitting into multiple lines excessively.

As an example:

        await role.edit(reason=f"Role unlocked by {ctx.author}", mentionable=True)

In...

#

Nobody should be able to sign in using usernames and passwords, except a sort of superadmin account which we can store in the keepass. This account should only be able to sign in via /admin, although you don't have to actually restrict this, we're just not gonna attach any social to it.

That sounds fine - I need to investigate specifically how redirecting to login works, as right now it goes to the admin login regardless of whether allauth is there or not. My worry is that in making alla...

ebon magnetBOT
#

Build 20191005.13 failed

Requested by

GitHub

Duration

00:01:17

Build pipeline

Bot

ebon magnetBOT
#

Build 20191005.14 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191005.15 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
#

Thanks for addressing the previous suggestions.

I see you're allowing the event to still wait when a standard user mentions the role. I would suggest actually allowing the role to relock in that instance, as typically if it's meant maliciously, they'll spam the role numerous times while they can. Due to this, what should probably instead happen is:

  • check checks that the message is mentioning the correct role
  • the wait_for returns a valid message
  • the message.author is checked to ...
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191005.3 succeeded

Requested by

GitHub

Duration

00:02:01

Build pipeline

Site

regal archBOT
regal archBOT
regal archBOT
#

It strikes me as unnecessarily often to check every hour if it's been a week yet. that means we're doing 167 of these checks that return None for every one that does something.

I'm thinking something like 12 or even 24 hours is plenty. Even if the message is skewed by 23 hours every couple of weeks, it's not at all critical that this happens the same time every week or that there's exactly one week between each of these.

#

I'm wondering if it might be better to be more specific about the message to check. There is a small chance that the last message will be the bot saying "@someuser Please type !accept to verify that you have ...", which the bot will do whenever someone types something other than !accept. This message stays for about 10 or 15 seconds before being deleted. in other words, there's a chance this will fail even when it shouldn't.

Of course, the price for such a failure is very low, it jus...

ebon magnetBOT
#

Build 20191005.4 succeeded

Requested by

GitHub

Duration

00:01:55

Build pipeline

Site

regal archBOT
#

Do I understand correctly?

  • If "(no reason recorded)" approach is used, it may end up in keeping a duplicate start nomination because of that bug you described with simultaneously nominating someone.
  • If the current approach is used, it can result in a skew as you described in the other comment, but in practice, this won't happen given our historical data
  • This check for if an active infraction already exists is not just there as a safety measure but actually has a use for the simul...
ebon magnetBOT
#

Build 20191005.16 succeeded

Requested by

GitHub

Duration

00:01:26

Build pipeline

Bot

regal archBOT
#

Not sure if it the right place, but:

This page: https://pythondiscord.com/pages/contributing/bot/ could be better (although it is already pretty good)

Rename #bot-commandsand #ot-offtopics to bot and off-topic-0 to actually meet with their names in config.yml. Explicit more that the bot_token has to be put in the .envfile.

Precise somewhere that not all cogs are loaded in DEBUG mode, I lost one hour trying to figure why verification.py was not loading.

What do yo...

regal archBOT
#

Not sure if it the right place, but:

This page: https://pythondiscord.com/pages/contributing/bot/ could be better (although it is already pretty good)

Rename #bot-commandsand #ot-offtopics to bot and off-topic-0 to actually meet with their names in config.yml. Explicit more that the bot_token has to be put in the .envfile.

Precise somewhere that not all cogs are loaded in DEBUG mode, I lost one hour trying to figure why verification.py was not loading.

What do yo...

#

I appreciate the feedback, these are good suggestions. I would suggest we make the following changes:

  • Let's change the names of the channels in default-config.yml to actually match the channel name. It should be called bot-commands, not just bot.
  • Let's change the guide so that we create all three off-topic channels, and simply name them #off-topic-0, #off-topic-1 and #off-topic-2 to match the constants.
  • I'm gonna discuss with the core devs whether perhaps we should just load ...
regal archBOT
ebon magnetBOT
#

Build 20191005.1 succeeded

Requested by

GitHub

Duration

00:02:12

Build pipeline

Snekbox

regal archBOT
north knotBOT
ebon magnetBOT
#

Build 20191005.2 succeeded

Requested by

GitHub

Duration

00:03:00

Build pipeline

Snekbox

ebon magnetBOT
#

Build 20191006.1 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
regal archBOT
regal archBOT
north knotBOT
ebon magnetBOT
#

Build 20191006.1 succeeded

Requested by

Joseph Banks

Duration

00:03:46

Build pipeline

Site

regal archBOT
#

I've been asked to make the messages look better than the current state of my PR. I'm going to do that by putting floating messages into one of the corners - however, the JS in django-simple-bulma uses the CSS display property to hide the messages when they're "closed".

This works fine, but can't be animated. Would it be better to write our own JS for this in order to allow for that?

#
[python-discord/branding] New branch created: \#029\-blank\-banners
regal archBOT
ebon magnetBOT
#

Build 20191006.2 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191006.3 succeeded

Requested by

GitHub

Duration

00:01:31

Build pipeline

Bot

regal archBOT
#

However I also prefer the previous solid coloured message box over that one.

I designed them this way because lemon said he didn't really like the message boxes being so brightly coloured and in your face - I kind of agree, tbh.

I suggested this design since it matches up with Discord embeds.

Eventually I'd like to see a global dark theme we can choose for the site, so I'd prefer if the message box matches the current default light theme.

Alright, that's no problem. Both types...

#

I actually prefer the light ones myself, I think they fit better. They slide in, so they should be fairly obvious (especially when they overlap content).

By the way, I just realised that the current login system isn't quite kosher - need to actually bring people to a page to login so they can provide consent. That's alright, though.

regal archBOT
#

Some progress has been made today.

First off, @lemonsaurus asked me to look into making the Bulma colours less vibrant. See below for what I've come up with (don't worry about text colour for now). Please let me know what you all think!

Bulma Colours

Secondly, I've done a good bit of work on the login flow, and it's now functional to the specs we're looking for, as least as far as I can tell....

#

While trying to fix #389 , I just found that there was a feature to detect and remove the embed message if the author did fix his previous code. Nice, but it is not displayed at all. The embed message should display it clearly. Currently the message is:

"It looks like you're trying to paste code into this channel. Discord has support for Markdown, which allows you to post code with full syntax highlighting. Please use these whenever you paste code, as this helps improve the legibili...

regal archBOT
regal archBOT
regal archBOT
#
[python-discord/bot] branch deleted: doc\-fix
north knotBOT
ebon magnetBOT
#

Build 20191006.4 succeeded

Requested by

GitHub

Duration

00:03:34

Build pipeline

Bot

oak estuaryBOT
regal archBOT
ebon magnetBOT
#

Build 20191006.5 succeeded

Requested by

GitHub

Duration

00:01:32

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191006.2 failed

Requested by

GitHub

Duration

00:01:50

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191006.3 succeeded

Requested by

GitHub

Duration

00:02:03

Build pipeline

Site

#

Build 20191006.6 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

north knotBOT
ebon magnetBOT
#

Build 20191006.7 succeeded

Requested by

GitHub

Duration

00:03:33

Build pipeline

Bot

oak estuaryBOT
ebon magnetBOT
#

Build 20191006.8 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

regal archBOT
regal archBOT
north knotBOT
#

Postgres backup completed!

regal archBOT
#

I think that the intention of loading the cog is clear when someone tries to reload a cog, so I don't mind this behavior. The alternative proposal, reloading when someone tries to load something, sounds more counter-intuitive to me. If I recall correctly, the previous version with the misnomer cogs denied both, but I often found it annoying that it wouldn't just load an extension on reload when it wasn't loaded.

#

As far as I can tell, it will not iterate twice by importing it here, since it has already been imported when we load the alias cog and Python will not import it again. I've added a temporary logging call and that seems to confirm that the code is just executed once. It's only when I reload the extensions extension that the logging call is made again, which is to be expected, since discord.py explicitly makes sure to re-import the module to refresh the code.

#

Is there any particular reason why you allow multiple extensions to be reloaded at once, but don't allow multiple extensions to be loaded or unloaded at once? This feels like an unnecessary break of symmetry between the sub-commands to me.

Now, in your current version, we could use reload to load multiple extensions at once if they're unloaded, but that feels like a bit of a hack to me.

#

The docstring leads me to believe that providing a * or ** as the single argument to this subcommand would respectively reload all the loaded cogs or all of the cogs regardless of their status. However, this if-else block will call the self.manage method directly when a single argument is provided. Since self.manage does not have any logic to handle asterisk characters, it will fail with:

Oct 07 09:35:01 Bot: |               bot.cogs.extensions |    ERROR | Extension '*' f...
regal archBOT
#

That's on me, then. I never noticed that we had this functionality in the old version, I thought you added this handy feature. I don't think it's necessary, it just struck me as an asymmetry when reading the code. I think it could be a nice refinement to make the sub-commands work in a consistent manner, but I'm not opposed to keeping the current version either.

I'll leave this conversation open, but if no one else wants this, we can just close it. If we miss it down the line, we can alwa...

regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191007.1 succeeded

Requested by

GitHub

Duration

00:01:42

Build pipeline

Bot

#

Build 20191007.3 succeeded

Requested by

GitHub

Duration

00:01:43

Build pipeline

Bot

#

Build 20191007.4 succeeded

Requested by

GitHub

Duration

00:01:47

Build pipeline

Bot

regal archBOT
#

Currently, the #user-log channel only shows that a user left if they voluntarily leave the server. It should also include members leaving the server due to any moderator action taken.

Implementation Details

  • Log member leaving due to any reason, voluntary or involuntary, to #user-log
  • Show that the member left due to moderator action, eg. User banned/User temporarily banned as the title
regal archBOT
#
[python-discord/site] New branch created: \#421\-reminder\-jump\_url
ebon magnetBOT
#

Build 20191007.1 failed

Requested by

GitHub

Duration

00:01:33

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191007.2 failed

Requested by

GitHub

Duration

00:01:31

Build pipeline

Site

regal archBOT
#

As far as I can tell, your pull request does not include the migration files needed to migrate the database according to the new model specifications. You also need to think about what the database base should do with existing entries: If we create a new jump_url column, which value should we use for existing entries that were set before this column existed?

In addition, the [serializer for the reminder model](https://github.com/python-discord/site/blob/d87226479a53708d6fdb5d39a8e87b12b1...

ebon magnetBOT
#

Build 20191007.3 failed

Requested by

GitHub

Duration

00:01:25

Build pipeline

Site

regal archBOT
ebon magnetBOT
#

Build 20191007.5 failed

Requested by

GitHub

Duration

00:01:30

Build pipeline

Site

regal archBOT
#

If you want to contribute to the site repository, then it's a good idea to get familiar with Django and, if you working on something API-related, Django REST framework. The official Django documentation has a great tutorial that covers the basics of working with Django, including models and the related migrations that need to take place to get the database up-to-date with the latest specification of t...

regal archBOT
#
[python-discord/site] branch deleted: \#421\-reminder\-jump\_url
regal archBOT
#

This PR fix #389

Split the token_remover in two functions, one that checks that there is a token in the message (is_token_in_message), and the other takes the actions (deleting the message, etc.)
This new function is_token_in_message is reused in cogs/bot.py to know if the poorly formatted code contains a token. If it true, then the embed message is not displayed, since token_remover.py is already in charge.

ebon magnetBOT
#

Build 20191007.5 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

#

Build 20191007.6 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
#

@mathsman5133 you could work on this or you are going to work on this? it's yours if you want it.

If you're doing this, I have one more request for this cog, which came up in the last staff meeting. Instead of relaying every post that is posted on /r/python, it would be nice if it just posted the top 3 posts that day, once every day. Currently, the channel is very noisy and I doubt anyone really uses it for anything except the weekly top 3 in the pins.

ebon magnetBOT
#

Build 20191007.7 succeeded

Requested by

GitHub

Duration

00:01:40

Build pipeline

Bot

regal archBOT
#

We're not really sure if this is still a problem. There have been major changes to the bug since it was last observed. And even if it is still a problem;
A) It's a bit of a heisenbug, so it'll be very hard to test if it's been solved.
B) The correct solution is probably a rewrite of the Reminder cog, so we can provide features like recurring reminders.
C) There's been talk of putting some NLP into the rewrite so we can have stuff like `!remind "@...

ebon magnetBOT
#

Build 20191007.8 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

regal archBOT
#

I've add support for this now. The only caveat is that for !ext load, when multiple extensions are given, if any of those are already loaded, they will still be displayed as loaded (i.e. included in the total load count and no error shown). When a single extension is given, it will show an error if it's already loaded. The same applies to !ext unload. I figured this isn't a big deal and makes implementation simpler.

ebon magnetBOT
#

Build 20191007.9 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

#

Build 20191007.10 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191007.11 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191007.12 failed

Requested by

GitHub

Duration

00:01:21

Build pipeline

Bot

#

Build 20191007.13 succeeded

Requested by

GitHub

Duration

00:01:35

Build pipeline

Bot

regal archBOT
regal archBOT
#
[python-discord/site] New branch created: active\-infractions\-validation
regal archBOT
#

This pull request needs to be manually merged after #269 has been merged to avoid conflicting migration files.

This pull request adds validation rules to the API to validate infractions based on the active field. This means that the API will now reject active infractions of types that should never be active (notes, warnings, and kicks) and only accept one active infraction per user for the other types of infractions (mute, ban, watch, superstar).

In addition, this pull requests a...

ebon magnetBOT
#

Build 20191007.6 succeeded

Requested by

GitHub

Duration

00:02:27

Build pipeline

Site

regal archBOT
regal archBOT
#
  • The auto-posting has been removed as it was spammy and few used it.
  • Instead a daily top posting loop has been created.
  • Both loops will post at midnight
  • As before, the weekly top posts will be pinned.
  • A webhook id for the Reddit channel has been set in constants and config, but will need to be created by an admin (and real ID set).
  • I set the webhook author to be what was previously the content of the message - it looks clean to me, but here is an example:

![image](https://u...

ebon magnetBOT
#

Build 20191008.1 failed

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

north knotBOT
#

Postgres backup completed!

ebon magnetBOT
#

Build 20191008.2 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

regal archBOT
#

Discord.py redesigned and created how help commands work - some helpful links:

This was way back before rewrite was released. Since then there has been at least 1 (ctx.send_help) helper added that works with an updated implementation...

regal archBOT
ebon magnetBOT
#

Build 20191008.3 succeeded

Requested by

GitHub

Duration

00:01:51

Build pipeline

Bot

regal archBOT
#

The discord.py Tasks extensions allows you to pass a single (or a list of) datetime.time to the time parameter of loop() to trigger an iteration at the specified time. That way, we don't have to manually calculate seconds_until and include a asyncio.sleep.

I think this should do it:

import datetime
@loop(time=datetime.time.min)

The use of datetime.time.min guarantees we're aiming for the midnight exactly, although I don't think a few seconds really matter.

#

I don't see a way to avoid some logic here by purely using the Task extension, as you only specify a target time not a day in the week. One way we could avoid having to calculate the delay and execute the sleep ourselves is by having the daily task check if it's Monday and, if so, trigger the weekly top posts function.

This means that the daily posts coroutine wakes up at every midnight and if it's Monday, it will also trigger the weekly top posts coroutine to do its business.

regal archBOT
ebon magnetBOT
#

Build 20191008.1 succeeded

Requested by

GitHub

Duration

00:02:09

Build pipeline

Site

regal archBOT
#
[python-discord/bot] branch deleted: moderation\-cleanup
north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191008.4 succeeded

Requested by

GitHub

Duration

00:03:56

Build pipeline

Bot

ebon magnetBOT
#

Build 20191008.5 failed

Requested by

GitHub

Duration

00:01:22

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] New branch created: show\-reason\-bot\-actor\-infractions
ebon magnetBOT
#

Build 20191008.6 succeeded

Requested by

GitHub

Duration

00:01:39

Build pipeline

Bot

regal archBOT
#

This PR adds the reason back to the infraction confirmation message the bot sends after successfully applying an infraction, but only if the actor is the bot itself. The reason is that if the bot itself invokes the infraction, having the reason it did that stated in the confirmation message will give context to what's going to those involved in the conversation.

Before
no_reason

...

ebon magnetBOT
#

Build 20191008.7 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

regal archBOT
#

I've managed to trace the problem to users setting a nickname if they had none or resetting their nickname to their username (i.e., removing their server-specific nickname). What happens is that when people remove or add a nickname, the old_value or new_value is None.

For instance, resetting a nickname results in the following data:

'nick': {
    'old_type': <class 'str'>,
    'new_type': <class 'NoneType'>,
    'old_value': 'Nickname',
    'new_value': None
}

Si...

regal archBOT
#
[python-discord/bot] branch deleted: show\-reason\-bot\-actor\-infractions
north knotBOT
ebon magnetBOT
#

Build 20191008.8 succeeded

Requested by

GitHub

Duration

00:03:27

Build pipeline

Bot

oak estuaryBOT
regal archBOT
#
[python-discord/bot] New branch created: user\-log\-display\-name\-changes
#

Recently, we discovered that not all display name changes were logged to the #user-log channel. This problem was caused by the old_value or the new_value showing up as None when a user sets or removes a guild-specific nickname. Since we ignore changes in which either the old_value or the new_value is None, we did not log these None->nick or nick->None events.

As we are mainly interested in the display name of the user, and the display name is either equal to the user's guil...

ebon magnetBOT
#

Build 20191008.9 succeeded

Requested by

GitHub

Duration

00:01:34

Build pipeline

Bot

regal archBOT
regal archBOT
#
[python-discord/site] New branch created: fix\-home\-responsive
#
[python-discord/site] branch deleted: fix\-home\-responsive
#
[python-discord/site] New branch created: fix\-home\-responsive
#
[python-discord/site] branch deleted: fix\-home\-responsive
#
[python-discord/site] New branch created: fix\-home\-responsive
ebon magnetBOT
#

Build 20191008.2 succeeded

Requested by

GitHub

Duration

00:01:52

Build pipeline

Site

regal archBOT
regal archBOT
#
[python-discord/bot] New branch created: token\-regex\-tweak
#

The existing bot token regex pattern ([^\s\.]+\.[^\s\.]+\.[^\s\.]+) fails to detect tokens in most use-cases beyond simple assignment.

e.g. this would be caught:

token = <token>

While these would not:

print(<token>)
bot.run(<token>)

To mitigate this, the character exclusion has been expanded to include some of the more commonly used anchors: [^\s\.()\"']+\.[^\s\.()\"']+\.[^\s\.()\"']+ in order to try and limit what the regex is capturing as a poten...

ebon magnetBOT
#

Build 20191009.1 succeeded

Requested by

GitHub

Duration

00:01:37

Build pipeline

Bot

native joltBOT
#

With the release of Python 3.8 comes some things to do for compatibility!

  • [ ] flake8 compatibility check (pending release of flake8 v3.8)
  • [ ] Investigate changes to ast in 3.8
    • [ ] Native type comment support, likely removing dependency on typed-ast for Python versions < 3.8
    • [ ] Nodes with line & column offsets now will also have end line and column offsets, we’re currently manually calculating these
  • [ ] See if [positional-only arguments](https://www.python.org/dev/pep...
north knotBOT
#

Postgres backup completed!

regal archBOT
#

The more I look into this, the more complicated it becomes. The main problem is that there isn't a single unit that processes the GET parameters, but multiple independent "filter backends" that are all unaware of the parameters used by the other "filter backends" in use or even which filters are used for that view at all.

As an example, the infraction viewset uses these filter back-end settings¹:

    filter_backends = (DjangoFilterBackend, SearchFilter, OrderingFilter)
    filt...
regal archBOT
regal archBOT
regal archBOT
ebon magnetBOT
#

Build 20191009.2 succeeded

Requested by

GitHub

Duration

00:01:38

Build pipeline

Bot

regal archBOT
#
[python-discord/bot] branch deleted: user\-log\-display\-name\-changes
north knotBOT
oak estuaryBOT
ebon magnetBOT
#

Build 20191009.3 succeeded

Requested by

GitHub

Duration

00:03:30

Build pipeline

Bot

regal archBOT
ebon magnetBOT
#

Build 20191009.4 succeeded

Requested by

GitHub

Duration

00:01:36

Build pipeline

Bot

regal archBOT