Implemented a rebase feature #635
Conversation
d94d369 to
34822ed
Compare
|
awesome! I'll take a look and do some testing soon |
|
Hi @dabutvin, I hope you're well! We just wanted to check in regarding the status of the PR. Implementing this is a part of an assignment, in a course at KTH for our master program, that has the deadline on the 30th of April. No pressure though, but it would be so great to get feedback before that if possible. Thank you in advance! |
|
@s1grun understood. I will do my best 😄 |
|
Hi @dabutvin, Just touching base, have you had any time to take a look at the PR? |
dabutvin
left a comment
There was a problem hiding this comment.
Hey great work so far!
Check out my comment about automatically running the rebase for everyone instead of requiring the issue comment.
Let me know what you think!
🤠
| } | ||
|
|
||
| repo.Commit(commitMessage, signature, signature); | ||
| } |
There was a problem hiding this comment.
Really interesting thought about optimizing the process to only compress the new or modified images 👍
This is something I've thought about in the past, and it could really reduce the cost of running the service.
Having this as part of the rebase is one small part of the overall optimization, because as it stands, every time a new image is added, when we are not rebasing, we run the optimizer over every single image anyway.
A huge win would be to figure out how to do this outside of the rebase for all ongoing optimization runs.
Because of the complexity here, I'd like to pull this functionality into a separate PR. Let's get the rebase feature all finished up and shipped and then come back to focus on optimizing the compute resources looking at the whole system. For the first iteration, when we rebase, we can trigger a full optimization run.
There was a problem hiding this comment.
OK, removing this for now 👍
For optimizing the whole thing, what do you think about a checksum-based solution? We could store all (filename,checksum) entries on a table, and compare every time the compression function is called, therefore compressing only the images in which the checksum does not match.
In terms of operation cost, this solution would mean a storage/processing trade-off. I believe in the long run, and specially in repositories with hundreds/thousands of images the trade-off would be justified.
There was a problem hiding this comment.
that's a cool idea 👍 and i think you're right, could be a huge win in the long run.
Not sure how familiar you with azure storage, but ideally we could pull this off with using either blobs or tables https://docs.microsoft.com/en-us/azure/storage/common/storage-introduction in a performant way.
|
Hey! Thanks for the review! We will address your feedback soon and update the PR accordingly. 👍🏻 |
Co-Authored-By: Sigrun Arna Sigurdardottir <[email protected]> Co-Authored-By: Javier Ron <[email protected]>
|
@dabutvin The changes you requested are now uploaded 😎 |
- Move ParseCommitMessage functiopn to CommitMessage.cs - Validate that head commit of imgbot branch is made by imgbot - Remove re-compress optimization - Remove issue_comment hook and rebase if branch already exists Co-Authored-by: Sigrun Arna Sigurdardottir <[email protected]> Co-Authored-by: Javier Ron <[email protected]>
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
@dabutvin Any update on this? I'll be glad to keep working on this and get it merged if it's still relevant. |
|
thanks for the reminder @javierron |
dabutvin
left a comment
There was a problem hiding this comment.
Works great! 🎉 🎉
Thanks so much for working through this and being patient. I think people are really going to appreciate this one.
Here is an implementation of the feature described on https://github.com/dabutvin/Imgbot/issues/352
This was implemented such that when a rebase is triggered, only the conflicted images and possibly new images would be re-compressed.
In order for this to work, the app should be updated to trigger the issue_comment webhook.
Authors: @s1grun and @javierron