Restructure event directories#129
Merged
Merged
Conversation
added 3 commits
March 6, 2021 15:33
Move all files from the 'seasonal' directory into 'events' and adjust internal event structure for the new schema. A new directory 'jams' contains jam-related assets. These may eventually live in 'events' as well, but since the event-calender is not officially decided yet, I decided to keep them separately. All files removed by this commit were duplicates.
For now, the files contain the start and end dates, and a header. Descriptions will be added later. The Evergreen season is a special case, registering as a 'fallback', rather than having a defined period. This is the branding that we use when no other event is active. By default, we understand the 'fallback' key to be False.
6 tasks
added 5 commits
March 15, 2021 20:50
This also adds a 'meta.md' for the new event.
Use the evergreen logo SVG edited to use colours of the Easter logo.
Contributor
Author
|
This PR will now also add the missing Easter banner (#127). It's a colour edit of the evergreen one to match the Easter logo: PR includes both the SVG base & a rendered PNG. |
Merged
Many of these were contributed by DawnOfMidnight! Co-authored-by: DawnOfMidnight <78233879+dawnofmidnight@users.noreply.github.com>
Contributor
Author
|
🙏 Ready for review! |
lemonsaurus
previously approved these changes
Mar 29, 2021
Contributor
lemonsaurus
left a comment
There was a problem hiding this comment.
This looks excellent to me. Very well done.
Shivansh-007
previously approved these changes
Mar 29, 2021
Contributor
Shivansh-007
left a comment
There was a problem hiding this comment.
Looks good! Just 2 grammar changes (can be ignored) and it would be perfect!
|
|
||
| ## Automatic validation | ||
|
|
||
| Fortunately, it is not necessarily to manually verify that all events are configured properly w.r.t. the requirements explained above. The `validation.py` script contains logic to ascertain correct setup, and will automatically run in CI on pull requests to prevent a broken configuration from reaching the production branch. |
Contributor
There was a problem hiding this comment.
Suggested change
| Fortunately, it is not necessarily to manually verify that all events are configured properly w.r.t. the requirements explained above. The `validation.py` script contains logic to ascertain correct setup, and will automatically run in CI on pull requests to prevent a broken configuration from reaching the production branch. | |
| Fortunately, it is not necessary to manually verify that all events are configured properly w.r.t. the requirements explained above. The `validation.py` script contains logic to ascertain correct setup, and will automatically run in CI on pull requests to prevent a broken configuration from reaching the production branch. |
|
|
||
| The markdown section of the meta file then contains the event's description. Descriptions are made available directly in the Discord guild as embeds sent by the Python bot. For formatting, use Discord's watered down Markdown ~ keep in mind that e.g. the `#` symbol does not create a heading. | ||
|
|
||
| A description is required to exist, and must be at most 2048 characters in length in order to fit into a Discord embed. |
Contributor
There was a problem hiding this comment.
Suggested change
| A description is required to exist, and must be at most 2048 characters in length in order to fit into a Discord embed. | |
| A description is required to exist, and must be at most 2048 characters in length to fit into a Discord embed. |
|
|
||
| ## Event directory structure | ||
|
|
||
| In order for an event directory to be valid, it has to contain the following assets. |
Contributor
There was a problem hiding this comment.
Suggested change
| In order for an event directory to be valid, it has to contain the following assets. | |
| For an event directory to be valid, it has to contain the following assets. |
in order for seems a bit wordy here, it is grammatically correct, but keeping it concise is better.
Co-authored-by: Shivansh-007 <Shivansh-007@users.noreply.github.com>
Contributor
Author
|
@lemonsaurus Thank you for the review! @Shivansh-007 Thanks, applied in f8c4282. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.


Closes #123.
Closes #127.
This PR implements the changes proposed in #123.
The
eventsdirectory (previouslyseasonal) is restructured and configured withmeta.mdfiles to be used by Python's new branding manager. A validation script is added, which will run in CI and validate event configuration to ensure that a broken setup doesn't reach themainbranch.What has changed?
The changes are not too dramatic - the new
eventsdirectory is very similar in structure to what we had before. The new addition aremeta.mdfiles, which use frontloaded YAML to provide each event with a description and a duration. These files are fetched and read by the Python bot.The exact structure that events must comply with in order to pass validation is documented in the new
events/README.md. I will therefore not go into too much detail, as I assume that reviewers will read the README anyway.Branding for past one-time events (i.e. jams) is not included in the
eventsdirectory. I've placed those assets into a paralleljamsdirectory. It is assumed that the branding manager will be used to manage jam assets in the future, but it does not make sense to include past events as they will never be applied again.Validation & CI
I have added a validation script that lives in the
eventsdirectory. It's a few lines of code that will run through the directory and verify that each event is correctly set up, and that there are no collisions between events. It depends on the YAML parser declared in the requirements file. The script exits with a non-0 code if it detects errors.I have also added a GH Actions workflow that runs this script on pull requests and new commits on
main. However, it seems that since I am working from a fork, we will not be able to run the workflow until the PR is merged into the upstream. Reviewers can run the script locally (see the events README for instructions). I have tested and verified that it fails the workflow if errors are found.PyDis projects use a custom workflow for sending status embeds to the
#mod-logchannel, reporting whether CI passed. Because I have struggled a little bit with understanding how this workflow works, and didn't want to blindly copy-paste it without being able to test, I'd prefer for it to be added later (directly in upstream, and probably by someone more experienced). So for now the CI runs and validates events, but does not produce a cute status embed.Assets
This PR adds an Easter banner, which was previously missing. It is a simple colour edit of the evergreen SVG:
Event descriptions
With the help of @dawnofmidnight we have added a short description for each event. The descriptions are pulled by Python and presented as embeds:
Each description links Wikipedia or similar for more information. I assume there may be some discussion regarding the descriptions. I wasn't entirely sure on how to approach them.
Calendar
Quick overview of current configuration, formatted as
event_name[start_day-end_day]. Both bounds inclusive.Python-side, a calendar overview can be produced on-demand from the fetched events:
I'd recommend that reviewers also read the Python-side PR description.