feat: create release and add APK to CI release #2472
Conversation
| - name: Compute the release tag for continues ci build | ||
| if: ${{ inputs.tag == 'main' }} | ||
| run: | | ||
| echo "release_tag=v`date '+%Y-%m-%d %H:%M:%S'`" >> $GITHUB_ENV |
There was a problem hiding this comment.
❓ why not simply call it latest?
There was a problem hiding this comment.
imho latest is meant to be the "real" latest release, i.e. our proper release
There was a problem hiding this comment.
How about preview? I don't know, I am a bit worried that we will get hundreds of tags which will pollute our release page.
There was a problem hiding this comment.
Tags are meant to be unique and immutable, i.e. we shouldn't have a moving tag which is moved for every new release.
I am a bit worried that we will get hundreds of tags which will pollute our release page.
This will indeed happen, but why is it a problem?
There was a problem hiding this comment.
Tags are meant to be unique and immutable, i.e. we shouldn't have a moving tag which is moved for every new release.
Are you sure about that? Some tags have special meaning and change frequently. E.g. latest.
This will indeed happen, but why is it a problem?
I don't know. It doesn't "feel" right to have a full release for every merged PR. But we can give it a go and see if it annoys us.
There was a problem hiding this comment.
Are you sure about that? Some tags have special meaning and change frequently. E.g. latest.
Very certain about this. Imho there is no best practice around having a latest tag neither.
Unlike branches, tags are meant to be immutable, you can delete them but this might result in problems down the lines, e.g. we would need to
- delete the released files or overwrite it
- you don't know which commit latest is based on
- you can use tags to checkout and build your work on, if you do this and the tag gets deleted and recreated you will have problems.
I don't know. It doesn't "feel" right to have a full release for every merged PR. But we can give it a go and see if it annoys us.
If this is the case, maybe we shouldn't do this after all 🤷.
An alternative would be to simply do nightly releases.
| name: ${{ env.release_tag }} | ||
| tag_name: ${{ env.release_tag }} | ||
| target_commitish: main | ||
| generate_release_notes: true |
There was a problem hiding this comment.
🔧 I don't think we need release notes for that.
There was a problem hiding this comment.
Imho they can come handy to know what was changed.
There was a problem hiding this comment.
Wouldn't this always be just one line?
There was a problem hiding this comment.
Right... it will always be the PR which was merged...
If android APK have been built for `main` we create a new release with the name and tag of format `vdate '+%Y-%m-%d %H:%M:%S'`. We can't (or shouldn't) use the same tag for this such as `nightly` because tags are meant to be immutable.
bonomat
force-pushed
the
feat/create-ci-release
branch
from
8ba18b0 to
a4a9750
Compare
|
Had a quick chat with @luckysori : we created a separate repository for this purpose: https://github.com/get10101/10101-test-apks . We will create the releases there to not pollute this repository. |
Whenever we build APKs for main, we create a new release with the date format and attach the APKs
Untested... YOLO.