/bounty 80

💎 $80 bounty • Mudlet

🔨 See instructions for compiling Mudlet

Steps to solve:

1. Start working: Comment /attempt #6101 with your implementation plan
2. Submit work: Create a pull request including /claim #6101 in the PR body to claim the bounty
3. Receive payment: 100% of the bounty is received 2-5 days post-reward. Make sure you are eligible for payouts

Thank you for contributing to Mudlet/Mudlet!

Add a bounty • Share on socials

💡 @ibishal submitted a pull request that claims the bounty. You can visit your bounty board to reward.

/attempt #6101

💡 @svallory submitted a pull request that claims the bounty. You can visit your bounty board to reward.

Hey, @vadi2!

I was going to leave this comment when I pushed the PR but totally forgot, sorry!

A couple of things need to be defined before I can complete this:

1. What's the trigger for the PR creation?

   Right now, the workflow is called whenever new branch or tag with a name starting with "release-" is created. It will create a new PR for branches but will fail for tags but I didn't see the point of adding checks until I knew what you want.

2. Should this run only on the main repo or also in forks?

   It may be the case that people work on forks and the PR should be created from the fork to the main repo. I need to know what exactly is the process here. Btw, by default, Github does not enable actions on forks, but they can be manually enabled, so take that into account

Also, I see there are other bounties for some other steps of the release process (which has a lot more steps). If you want, we can discuss the automation of the entire process. It may be easier (and cheaper) to have a single dev do it all instead of splitting it into multiple bounties pieces.

Hey @svallory!

Thanks for your interest and thought. It seems we have 2 competing attempts on this issue, so I will include @ibishal in this discussion as well.

Your observation is correct that the release process is currently pretty complex and takes a lot of time. That's why there hasn't been a Mudlet release in a while and we want to automate it to lessen the burden. @vadi2 gathered all the steps in https://wiki.mudlet.org/w/Release_Checklist.

Regarding your questions here:

1. I think the branch creation trigger is the correct place. The context of this is, that the version number update has to happen before any tag is set as this version will be included into the compiled binaries. This compilation of the release binaries will then most likely be triggered by tag creation. The release branch is for preparation of the release, which can happen already with the new version numbers I think.
2. Since we are preparing the release in the main repo, we currently only need this workflow to run in the context of the main repo.

I hope this answers the questions. Please feel free to ask for clarification or further details. And if I got something wrong, I'm sure @vadi2 will correct me 😅

Hey @keneanung!

The thing is that there are two ways this could go since, at this time, the branch creation requires manual intervention.

Path 1:

• the developer creates the branch locally
• updates the version manually
• pushes the branch to github

this gives more flexibility in branch naming as it only needs to start with release-

Path 2

• the developer creates the branch locally
• pushes the branch to Github
• the action reads the version from the branch name and updates the files

This saves the step of manually editing the files, but then restricts the branch naming. Also, in case of errors like an invalid version in the name or issues updating the files, there's no easy way to recover from the action and the developer will have to delete the branch and create a new one.

My 2 cents: I believe the automations are too granular and without a view of the automation flow (which will not necessarily follow the sequence on the wiki) it's hard to optimize steps individually.

That's why I proposed creating a bounty to plan the whole thing before breaking it apart

That sounds interesting, what do you have in mind? The overarching idea of these bounties is to streamline the whole release workflow.

That sounds interesting, what do you have in mind? The overarching idea of these bounties is to streamline the whole release workflow.

I think the best way to go about this is to schedule a meeting of 1-2hs with the person/people who is/are most familiar with the process. I don't mind helping you guys mapping this process out (regardless of getting future bounties or not).

You guys can find me on discord as svallory and ping me, or schedule a meeting here.

@svallory thanks for the offer! I've booked something in for next Wednesday at 8pm CET. Let's meet on our Discord: https://discord.gg/kuYvMQ9