Closed cnlangzi closed 1 year ago
Sorry for the late reply. Thanks for the patch. I will check it out.
Sorry for the late reply. Thanks for the patch. I will check it out.
don't merge it now. let me fix linux/arm issue first. https://github.com/herumi/bls-go-binary/issues/24
@cnlangzi Do you think it should be relatively easy to fix #24 ?
I would need this to be fixed in order to be able to compile my lib for darwin/arm64
@cnlangzi Do you think it should be relatively easy to fix #24 ?
I would need this to be fixed in order to be able to compile my lib for darwin/arm64
please use my fork to fix it as a workaround first. I will fix arm64 issue in this PR.
replace github.com/herumi/bls-go-binary => github.com/cnlangzi/bls-go-binary v1.30.7
This patch fails at "Create branch" at my test-bls-go-binary. https://github.com/herumi/test-bls-go-binary/actions/runs/5186125201/jobs/9346834393#step:3:47 Do you think it's necessary something to set up?
This patch fails at "Create branch" at my test-bls-go-binary. https://github.com/herumi/test-bls-go-binary/actions/runs/5186125201/jobs/9346834393#step:3:47 Do you think it's necessary something to set up?
delete release
on remote git first. and never update it manually.
Already up to date.
fatal: refusing to merge unrelated histories
Thank you. I'll try it.
used fixed branch to create release, and never delete it from git
It runs well if I removed a release tag. But the next time I tried it, I got the same error. Should I merge the generated release branch into the main?
used fixed branch to create release, and never delete it from git
It runs well if I removed a release tag. But the next time I tried it, I got the same error. Should I merge the generated release branch into the main?
delete any tag/branch which name is release
. it will be created and merged from release.yml. it worked on my test branch , you can have check on https://github.com/cnlangzi/bls-go-binary/actions/workflows/release.yml and https://github.com/cnlangzi/bls-go-binary/tree/fix/release_branch
- name: Create branch
env:
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # This token is provided by Actions, you do not need to create your own token
run: |
git pull
git checkout release 2>/dev/null || git checkout -b release
git merge origin/master -q -m "chore(git): merged latest master"
git submodule update --init --recursive
git config user.name github-actions
git config user.email github-actions@github.com
git push --set-upstream origin release
BTW: it will pull latest code from master
as default. if you test it on a dev branch , please uncomment it first
git merge origin/master -q -m "chore(git): merged latest master"
@herumi in general, it should be released from master only.
The latest release.yml of test-bls-go-binary seems to be able to build both amd64 and arm64 darwin binary.
The latest release.yml of test-bls-go-binary seems to be able to build both amd64 and arm64 darwin binary.
Good job. could you merge it on master first? I can update my fork, and verify it on our projects again.
Thank you for the patch. I've merged it.
delete
release
on remote git first. and never update it manually.
I don't understand your release.yml spec yet. First, I remove a release branch on the remote, which runs well. Next, when I run the release.yml after I update the master branch, is it necessary to remove the new release branch created by release.yml? If I don't remove it, it failed.
@herumi let me explain it
release
:
git pull
git checkout release 2>/dev/null || git checkout -b release
git merge origin/master -q -m "chore(git): merged latest master"
release
branch. so latest changes should be merged into current release
branch
- name: Create Release
id: create_release
run: gh release create "${{ github.event.inputs.version }}" -t "${{ github.event.inputs.version }}" --target "release" --latest
if it fails on git merge origin/master -q -m "chore(git): merged latest master"
, it means your release
was created from other branch instead of maser
. NB: new version should always be released from master
.
branch 'release' set up to track 'origin/release'.
fatal: refusing to merge unrelated histories
your release
has some issues.
for now, you can just do it like
release
branch from remotein next release, just do it like
and create branch
job always merge latest changes from master into release
, and create new version from latest codebase.
@herumi I think I know what happens there. it is broken by submodule https://github.com/cnlangzi/bls-go-binary/tree/master/src
make command
make some changes on submodule repos, we can't push it. let me try it.
@herumi try https://github.com/herumi/bls-go-binary/pull/27
for now, you can just do it like
* delete `release` branch from remote * create new version from master branch on
in next release, just do it like
* merge changes into master * create new version from master branch again on
I've merged #27 and set tag v2.1.2 and run release.yml with v2.1.2, then
* <cff34fc> 2023-06-08 [github-actions] (origin/release) fix(release): added libs for windows
* <aad2660> 2023-06-08 [github-actions] fix(release): added libs for ios/ios simulator
* <5f2174c> 2023-06-08 [github-actions] fix(release): added libs for darwin
* <fce82d5> 2023-06-08 [github-actions] fix(release): added libs for android
* <2d62ad6> 2023-06-08 [github-actions] fix(release): added libs for linux(amd64/arm64)
* <d90e514> 2023-06-08 [MITSUNARI Shigeo] (HEAD -> master, tag: v2.1.2, origin/master, origin/HEAD) Merge pull request #27 from cnlangzi/fix/clean_submodule
Sorry for the elementary question.
* create new version from master branch on
Does it mean creating a branch named v2.1.2, not a tag?
* merge changes into master
Does it mean merging the above origin/release
into master?
Does it mean creating a branch named v2.1.2, not a tag? no, just trigger workflow with
v2.1.2
from https://github.com/herumi/bls-go-binary/actions/workflows/release.yml, everything will be done automatically.Does it mean merging the above origin/release into master? No, we never merge origin/release into master. Because you don't push those binaries(bls/lib) on
master
.
so don't create tag manually, it will be created automatically by latest job create release
. just ignore release branch, and work as normal. trigger workflow if you want to release a new version
BTW: it is a workaround to merge master into release manually
to fix any conflicts. it is easiest way to fix the issue
branch 'release' set up to track 'origin/release'.
fatal: refusing to merge unrelated histories
Thanks for the detailed explanation. I tested it on test-bls-go-binary with minimized release.yml.
git push origin --delete release
git pull
From github.com:herumi/test-bls-go-binary
* [new branch] release -> origin/release
* [new tag] v2.3.1 -> v2.3.1
Then, I run the followings:
git checkout -b release
git reset --hard origin/release
git merge origin/master
git push origin release
And I run release.yml with v2.3.2 again, and it runs well. Is it a correct process?
@herumi yes. maybe reset --hard origin/release
is better to clean local git status. maybe also add git clean -d -f
. I think it is an issue on github runner by checkout action.
Thank you. I understood. It would be nice if it would automatically merge at the beginning of release.yml.
Fixes
Demo