Skip to content
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

infra: automatically create PR updating developement #7098

Open
wants to merge 9 commits into
base: development
Choose a base branch
from

Conversation

ibishal
Copy link

@ibishal ibishal commented Jan 20, 2024

closes #6101
/claim #6101

@ibishal ibishal requested a review from a team as a code owner January 20, 2024 19:25
@add-deployment-links
Copy link

add-deployment-links bot commented Jan 20, 2024

Hey there! Thanks for helping Mudlet improve. 🌟

Test versions

You can directly test the changes here:

No need to install anything - just unzip and run.
Let us know if it works well, and if it doesn't, please give details.

@ibishal ibishal changed the title ci: automatically create PR updating developement infra: automatically create PR updating developement Jan 20, 2024
echo "set(APP_VERSION ${{ env.APP_VERSION }})" >> CMakeLists.txt
echo "VERSION = ${{ env.VERSION }}" >> src/mudlet.pro

git add CMakeLists.txt src/mudlet.pro
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could be missing something, but does extracting these values and writing them back actually achieve something?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The extraction and writing back of values were intended for a scenario where you needed to dynamically update version numbers in your files based on the extracted values.
Dont i need them?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc @vadi2

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't follow. Mind rephrasing?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@vadi2 so i should extract version and app_version from the release event right?

.github/workflows/build-mudlet.yml Outdated Show resolved Hide resolved
.github/workflows/build-mudlet.yml Outdated Show resolved Hide resolved
@ibishal ibishal requested a review from vadi2 January 21, 2024 10:15

gh pr create --base development --head update-development-${{ github.run_number }} --title "Update development-${{ github.run_number }}" --body "Automatically generated PR to update development with release ${{ env.APP_VERSION }} "

git checkout developement
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this line needed? There's a typo here also.

@ibishal ibishal requested a review from vadi2 January 21, 2024 10:52
@ibishal
Copy link
Author

ibishal commented Jan 21, 2024

@vadi2 completely revamp my pr. Can you take a look

Copy link
Member

@keneanung keneanung left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR does not really set the version information in the right places. It rather appends new values for variables at the end of the files after they have been used.

Additionally, this needs to happen before a git tag is set, so the trigger is wrong. But to be fair, that information is missing in the original issue.

Comment on lines 22 to 25
VERSION=$APP_VERSION
echo "Extracted VERSION: $VERSION"
echo "VERSION=$VERSION" >> $GITHUB_ENV

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This block is completely unnecessary since you can just re-use the variable created above.

Comment on lines 28 to 29
echo "set(APP_VERSION ${{ env.APP_VERSION }})" >> CMakeLists.txt
echo "VERSION = ${{ env.VERSION }}" >> src/mudlet.pro
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two lines will append the versions to the "Makefiles". However this will not replace the current versions that are used within code and the files themselves. Rather, you'd have to replace the current variable content at the position it is right now.

@ibishal
Copy link
Author

ibishal commented Jan 23, 2024

This PR does not really set the version information in the right places. It rather appends new values for variables at the end of the files after they have been used.

Additionally, this needs to happen before a git tag is set, so the trigger is wrong. But to be fair, that information is missing in the original issue.

@keneanung can you review it once i have covered all the points that you have mentioned

@ibishal
Copy link
Author

ibishal commented Jan 23, 2024

Additionally, this needs to happen before a git tag is set, so the trigger is wrong. But to be fair, that information is missing in the original issue.

In the pr the workflow is triggered by a push event when a new tag is pushed
Am i getting it right?

cc @keneanung

@keneanung
Copy link
Member

keneanung commented Jan 23, 2024

The logic seems to be better now and replace the Mudlet version numbers.

However, I don't think the trigger is correct. But we have two competing PRs/claims on this bounty and the question was raised by the other party as well. I will attempt to answer this in the issue #6101 so it is visible to all parties.

Edit: #6101 (comment) point 1 should answer the trigger question

@ibishal
Copy link
Author

ibishal commented Jan 23, 2024

The logic seems to be better now and replace the Mudlet version numbers.

However, I don't think the trigger is correct. But we have two competing PRs/claims on this bounty and the question was raised by the other party as well. I will attempt to answer this in the issue #6101 so it is visible to all parties.

Edit: #6101 (comment) point 1 should answer the trigger question

@keneanung can you review it once now
This configuration will trigger the workflow when a new branch is pushed, and its name starts with release-

@ibishal
Copy link
Author

ibishal commented Jan 25, 2024

can you review it once
cc @keneanung @vadi2

@keneanung
Copy link
Member

This looks about to be right. However, we are currently discussing if we need to re-define the bounties. We noticed there are certain overlaps and need to define borders more clearly.

@ibishal
Copy link
Author

ibishal commented Jan 26, 2024

This looks about to be right. However, we are currently discussing if we need to re-define the bounties. We noticed there are certain overlaps and need to define borders more clearly.

ok lemme know about that

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Automatically create PRs updating development with the new release
3 participants