Writes Sidekiq job execution metrics to InfluxDB
vassilevsky/minimum-viable-ruby-gem 9
A working Ruby gem that has all the required information (builds without warnings)
Comment on problems in added lines of pull requests in Atlassian Bitbucket Server (formerly Stash)
Generates DOT representations of Statesman machines and runs dot to render them to PNGs
vassilevsky/abstract-code-coverage 3
Comprehensive source code coverage format specification
A calendar that shows all days in a straight horizontal line, like a time axis
Prioritize all your Todoist tasks faster
A curated list of awesome Ruby frameworks, libraries and resources. Inspired by awesome-php & awesome-python.
vassilevsky/environment-specific-config-files-considered-harmful 1
Environment-specific config files are a source of confusion and bugs in software projects and they should be eliminated
push eventfunbox/statesman-diagram
commit sha 253eac7ac1b74b6d28255b2b34b2c5b88a5aeed9
Improve README
commit sha 808ee91d35972a0f0e8299ebb256e58d199c6ad7
Remove Bash prompts for easier copy-pasting
commit sha d5e9c7147c1ec84f08b1b0d079f6bd2778110124
Merge pull request #4 from funbox/improvement/readme Improve README
push time in 6 days
push eventfunbox/statesman-diagram
commit sha 808ee91d35972a0f0e8299ebb256e58d199c6ad7
Remove Bash prompts for easier copy-pasting
push time in 6 days
push eventfunbox/sidekiq-influxdb
commit sha 4e7959a05e1ff3e0f4ab784a0aa76a6b900ae3f2
Improve README
commit sha 69f19d2c414b199433a41277a57d1ba66ab28583
Add LICENSE file
commit sha 4c5a0136ea0ac59015c74e246c3339b4f0ef05dc
Merge pull request #7 from funbox/improvement/readme Improve README and add LICENSE
push time in 6 days
push eventfunbox/face_control
commit sha 4b95705398589e5971487d79c3c8ee3f27987f4f
Improve README
commit sha 0f846c528aa6be14e8a8ebb9063d84376edbd28b
Merge pull request #19 from funbox/improvement/readme Improve README
push time in 6 days
Pull request review commentfunbox/pipeline-heavy-job-plugin
pipeline { ## Rationale -Typical Jenkins setup consists of the main server with several worker nodes.+A typical big Jenkins setup consists of the main server with several worker nodes. Each node has several slots. By default one build occupies one slot. Some builds will wait in a queue if there are no more free slots available. -Each node has a limited amount of resources like CPU, RAM, or network. Different-builds require different amount of these resources but each build occupies only-one slot. That is why in some cases one node can be overloaded and another-almost idle.+Each node has a limited amount of resources like CPU, RAM, or network bandwidth. Different+builds require different amounts of these resources but each build occupies only+one slot. That is why in some cases one node can be overloaded and another one+can be almost idle. -There are several ways to solve such a problem.+There are several ways to solve this problem. -Suppose we have two types of builds: light and heavy. Heavy build requires twice-twice as much resources as light one. Suppose we have two worker nodes. Each-node has enough resources to run two parallel light builds or one heavy.+Suppose we have two types of builds: light and heavy. A heavy build requires+twice as much resources as a light one. Suppose we have two worker nodes. Each+node has enough resources to run two parallel light builds or one heavy build. -We want to run as many builds as possible but do it in a such a way that none of+We want to run as many builds as possible but do it in such a way that none of the nodes will be overloaded. ### Separate worker for heavy builds -The idea is to configure Jenkins setup in such a way:+The idea is to configure Jenkins setup this way:
"such", but no "that". Doesn't feel right.
comment created time in 11 days
Pull request review commentfunbox/pipeline-heavy-job-plugin
pipeline { ## Rationale -Typical Jenkins setup consists of the main server with several worker nodes.+A typical big Jenkins setup consists of the main server with several worker nodes. Each node has several slots. By default one build occupies one slot. Some builds will wait in a queue if there are no more free slots available. -Each node has a limited amount of resources like CPU, RAM, or network. Different-builds require different amount of these resources but each build occupies only-one slot. That is why in some cases one node can be overloaded and another-almost idle.+Each node has a limited amount of resources like CPU, RAM, or network bandwidth. Different+builds require different amounts of these resources but each build occupies only+one slot. That is why in some cases one node can be overloaded and another one+can be almost idle. -There are several ways to solve such a problem.+There are several ways to solve this problem. -Suppose we have two types of builds: light and heavy. Heavy build requires twice-twice as much resources as light one. Suppose we have two worker nodes. Each-node has enough resources to run two parallel light builds or one heavy.+Suppose we have two types of builds: light and heavy. A heavy build requires+twice as much resources as a light one. Suppose we have two worker nodes. Each+node has enough resources to run two parallel light builds or one heavy build. -We want to run as many builds as possible but do it in a such a way that none of+We want to run as many builds as possible but do it in such a way that none of
"such ... that" is the most common form 👍
comment created time in 11 days
Pull request review commentfunbox/pipeline-heavy-job-plugin
pipeline { ## Rationale -Typical Jenkins setup consists of the main server with several worker nodes.+A typical big Jenkins setup consists of the main server with several worker nodes. Each node has several slots. By default one build occupies one slot. Some builds will wait in a queue if there are no more free slots available. -Each node has a limited amount of resources like CPU, RAM, or network. Different-builds require different amount of these resources but each build occupies only-one slot. That is why in some cases one node can be overloaded and another-almost idle.+Each node has a limited amount of resources like CPU, RAM, or network bandwidth. Different+builds require different amounts of these resources but each build occupies only+one slot. That is why in some cases one node can be overloaded and another one+can be almost idle. -There are several ways to solve such a problem.+There are several ways to solve this problem.
"such a" is very theoretical, but the problem is right here.
comment created time in 11 days
Pull request review commentfunbox/pipeline-heavy-job-plugin
pipeline { ## Rationale -Typical Jenkins setup consists of the main server with several worker nodes.+A typical big Jenkins setup consists of the main server with several worker nodes.
Typical typical Jenkins setup is one instance, I believe :)
comment created time in 11 days
Pull request review commentfunbox/pipeline-heavy-job-plugin
# Pipeline HeavyJob Plugin -This plugin allows defining job weight for pipeline projects as+This plugin allows defining job weights for pipeline projects like
Another option is "just as". But I thought that there are differences between plugins, so it's not a 100% match.
comment created time in 11 days
PR opened funbox/pipeline-heavy-job-plugin
pr created time in 11 days
issue commentForkIssues/Tracker
[Feature Request] Shortcut to jump to previous / next commit of the current branch
I did enable the filter already, thank you. Nice feature. But it does not solve the problem of merge bubbles.
The left arrow key collapses merge bubbles! That I didn't realize. This helps.
comment created time in 12 days
issue openedForkIssues/Tracker
[Feature Request] Shortcut to jump to previous / next commit of the current branch
Hello 🙃
In the commits list, when I press ⬆️ or ⬇️ the selection moves up and down exactly one commit.
If I hold Alt, it moves to the very beginning or end of the commit history.
There are no other ways of moving the selection (that I found).
What would be convenient for me to do is move the selection up or down one commit along the current branch only. This means to the next merge commit or standalone commit in the branch. Not to any commit in a merge bubble on the branch or any commit in a remote branch that is also visible in the view.
This would fit nicely onto Command + Up/Down, as right now it does the same as just Up/Down.
Thank you! 🙏
created time in 13 days
startedenspirit/bmg
started time in 21 days
pull request commentfunbox/statesman-diagram
Thanks, Joseph!
I have opened the depencencies requirements in the latest version. This should solve this problem.
comment created time in a month
pull request commentvassilevsky/statesman-diagram
allow higher versions of statesman
Thank you. Sorry for the delay. This is equivalent to an open-ended dependency, so I just did that. I've pushed version 0.1.3 of the gem. Hope this helps!
comment created time in 2 months
created tagvassilevsky/statesman-diagram
Generates DOT representations of Statesman machines and runs dot to render them to PNGs
created time in 2 months
push eventvassilevsky/statesman-diagram
commit sha a909c9b4c0aa41b9cc98466e0bc702b914daa745
Test on latest versions of MRI
commit sha a0b36dabdddf20c6c3b9783979415f8759b4582e
Vexor no longer seems to work
commit sha 56b51957b4a65a0c8519e8e2d5ac2791daa30be0
UTF-8 is the default for a long time
commit sha 7b1ddd2449c3a9a08d1b82b960a80682a6adbf22
Open ended dependencies for the future
commit sha 400f1d1c71c3c3e99d2ef74924d1c13de81245f4
v0.1.3
push time in 2 months
startedpalkan/rubanok
started time in 2 months
push eventvassilevsky/prioritist
commit sha 0be67a935d24548e489b4f8a2eb5ab6d5ee2f1ab
Sort tasks by priority
push time in 2 months
push eventvassilevsky/prioritist
commit sha e6edada9be0b2767fdd6038b6d0b256b4d20372f
New API endpoint
push time in 2 months
push eventvassilevsky/prioritist
commit sha dab93fee0ec6b4967eb7b3fcec39bf0ec716a7de
Added Done and Delete buttons
push time in 2 months
push eventvassilevsky/sentry-test
commit sha a7f9bb740fe110df1a898d98aad4146a24511057
test
push time in 2 months
push eventvassilevsky/sentry-test
commit sha dbada69ba4e0712afc8565519512d394d490d941
test
push time in 2 months
startedphotoprism/photoprism
started time in 2 months