-
Notifications
You must be signed in to change notification settings - Fork 710
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce a workflow updating the wishlist leaderboards #5085
Conversation
|
||
on: | ||
schedule: | ||
# Run every 3 hours |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think every day is fine, but probably this is cheap af :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The job takes ~1 minute 15 secs to run.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
default ubuntu-latest
are free for public repos
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks neat. Thanks!
q: how do you test this before merge? just curious.
There is just a single place where the result is saved ( Here's how I run it locally:
|
Okay, I meant more in the sense that how can you test GHA env locally. I recall I used some dockerized tool for this in the past and it was quite slow. |
Ah, in that case I run it in a real, playground github repo with small edits (to run on every By using a 3rd party tool to run an action locally, I still wouldn't be exactly sure that I have everything configured properly (for example permissions to edit an issue) - but maybe I'm wrong? |
) - Closes paritytech/eng-automation#11 The workflow periodically updates the leaderboards of the wishlist issues: paritytech#3900 and paritytech#3901 The code is adopted from [here](https://github.com/kianenigma/wishlist-tracker), with slight modifications. Previously, the score could be increased by the same person adding different reactions. Also, some wishes have a score of 0 - even thought there is a wish for them, because the author was not counted. Now, the score is a unique count of upvoters of the desired issue, upvoters of the wish comment, and the author of the wish comment. I changed the format to include the `Last updated:` at the bottom - it will be automatically updated.
A bit doubtful if this is working: #3901 (comment) For example this RFC has 16 ups, but is not listed. |
Ah, that's a PR, not an issue - I missed this! It's a quick fix: #5256 |
* master: (27 commits) Bridges improved tests and nits (#5128) Fix misleading comment about RewardHandler in epm config (#3095) Introduce a workflow updating the wishlist leaderboards (#5085) membership: Restructure pallet into separate files (#4536) Fix after ring-proof api change (#5126) Bump paritytech/review-bot from 2.4.0 to 2.5.0 (#5057) Bump docker/login-action from 3.0.0 to 3.3.0 (#5109) Bump docker/build-push-action from 5.1.0 to 6.5.0 (#5108) Bump peter-evans/create-pull-request from 5.0.0 to 6.1.0 (#5093) Tx Payment: drop ED requirements for tx payments with exchangeable asset (#4488) Remove `pallet-getter` usage from pallet-transaction-payment (#4970) pallet macro: do not generate try-runtime related code when frame-support doesn't have try-runtime. (#5099) fix(chain-spec): ChainSpecBuilder with object as default genesis (#4345) Migrate BEEFY BLS crypto to bls12-381 curve (#4931) Bump clap from 4.5.9 to 4.5.10 in the known_good_semver group (#5120) Use jobserver in wasm-builder to limit concurrency of spawned cargo processes (#4946) include events for voting (#4613) [subsystem-bench] Add mocks for own assignments triggering (#5042) Remove not-audited warning (#5114) hotfix: blockchain/backend: Skip genesis leaf to unblock syncing (#5103) ...
Addresses #5085 (comment) Luckily, in the rest of the script, github API allows (or forces?) us to read the state of PRs the same way as we read the state of issues, so it works without any more changes.
Can we make these jobs run only for the main repo and not for forks? I keep getting emails for failed jobs every few hours. There is an option to manually disable all jobs for a fork but I would say its better to add a Reference: https://github.com/orgs/community/discussions/26704 |
@mittal-parth Totally, thanks for reporting this. Created #5297. |
Addresses paritytech#5085 (comment) Luckily, in the rest of the script, github API allows (or forces?) us to read the state of PRs the same way as we read the state of issues, so it works without any more changes.
The workflow periodically updates the leaderboards of the wishlist issues: #3900 and #3901
The code is adopted from here, with slight modifications.
Previously, the score could be increased by the same person adding different reactions. Also, some wishes have a score of 0 - even thought there is a wish for them, because the author was not counted.
Now, the score is a unique count of upvoters of the desired issue, upvoters of the wish comment, and the author of the wish comment.
I changed the format to include the
Last updated:
at the bottom - it will be automatically updated.