docs(main): support arm64 release docs#2510
Conversation
|
Hey, I think it would be a good idea to add platforms for which we are supporting youki and their level of support in readme / docs. For example x64 has tier-1 support, where are after your PRs, we will have tier-3 support for arm , rest platforms are unsupported etc. |
jprendes
left a comment
There was a problem hiding this comment.
Thanks for working on this!
The README for libcontainer talks about how to build on musl.
Since your PR also adds support for musl builds, it would be nice to update that file.
Would you be happy to update it? Otherwise, please create an issue so that we remember to update it in a different PR :-)
| ```console | ||
| $ wget https://github.com/containers/youki/releases/download/v0.3.0/youki_0_3_0_linux.tar.gz | ||
| $ tar -zxvf youki_0_3_0_linux.tar.gz youki_0_3_0_linux/youki-0.3.0/youki | ||
| $ wget https://github.com/containers/youki/releases/download/v0.3.0/youki_0_3_0_linux-$(arch).tar.gz |
There was a problem hiding this comment.
shouldn't this be $(uname -m)?
daed095 to
09579a5
Compare
|
@utam0k In fact, I have an idea. The document does not need to be changed. When we officially release it, can we use the robot to automatically submit the commit without having to modify the document every time? using GitHub Action: peter-evans/create-pull-request@v5 |
| ```console | ||
| $ wget https://github.com/containers/youki/releases/download/v0.3.0/youki_0_3_0_linux.tar.gz | ||
| $ tar -zxvf youki_0_3_0_linux.tar.gz youki_0_3_0_linux/youki-0.3.0/youki | ||
| $ wget https://github.com/containers/youki/releases/download/v0.3.0/youki_0_3_0_linux-$(uname -m).tar.gz | ||
| $ tar -zxvf youki_0_3_0_linux-$(uname -m).tar.gz | ||
| # Maybe you need root privileges. | ||
| $ mv youki_0_3_0_linux/youki-0.3.0/youki /usr/local/bin/youki | ||
| $ rm -rf youki_0_3_0_linux.tar.gz youki_0_3_0_linux | ||
| $ mv youki_0_3_0_linux-$(uname -m)/youki-0.3.0/youki /usr/local/bin/youki | ||
| $ rm -rf youki_0_3_0_linux-$(uname -m).tar.gz youki_0_3_0_linux-$(uname -m) | ||
| ``` |
There was a problem hiding this comment.
Could you keep the method before v0.3.0 using <details>?
Like that:
version < v0.3.0
$ wget https://github.com/containers/youki/releases/download/v0.3.0/youki_0_3_0_linux.tar.gz
$ tar -zxvf youki_0_3_0_linux.tar.gz youki_0_3_0_linux/youki-0.3.0/youki
# Maybe you need root privileges.
$ mv youki_0_3_0_linux/youki-0.3.0/youki /usr/local/bin/youki
$ rm -rf youki_0_3_0_linux.tar.gz youki_0_3_0_linux
I appreciate your suggestion 🙏 But how about this in the case of this PR? I'd like to avoid the increase of load for the maintainers. |
32ee8d5 to
357c512
Compare
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #2510 +/- ##
==========================================
- Coverage 65.91% 65.91% -0.01%
==========================================
Files 133 133
Lines 16872 16872
==========================================
- Hits 11122 11121 -1
- Misses 5750 5751 +1 |
1a20392 to
5fd0be1
Compare
cuisongliu#42 This PR is my release test. GitHub Action automatically generates generator documentation when a new version is released. |
|
But this PR depends on #2498 |
5fd0be1 to
d52dcba
Compare
It looks great! May I ask you to provide the workflow? |
This PR already includes the submission of the workflow. https://github.com/containers/youki/pull/2510/files#diff-87db21a973eed4fef5f32b267aa60fcee5cbdf03c67fafdc2a9b553bb0b15f34R98 |
bf5d4dd to
8d2c2e8
Compare
Signed-off-by: cuisongliu <cuisongliu@qq.com>
8d2c2e8 to
d65d383
Compare
Signed-off-by: cuisongliu <cuisongliu@qq.com>
|
this pr is ready @utam0k |
| git grep -l "^version = .* # MARK: Version" | xargs sed -i 's/version = "[0-9]\.[0-9]\.[0-9]" # MARK: Version/version = "{{version}}" # MARK: Version/g' | ||
| sed -i s/_[0-9]_[0-9]_[0-9]_/_{{ replace(version, '.', '_') }}_/g docs/src/user/basic_setup.md | ||
| sed -i 's/[0-9]\.[0-9]\.[0-9]/{{version}}/g' docs/src/user/basic_setup.md |
There was a problem hiding this comment.
I took the script to implement it separately. There is something wrong with this writing, and there is a problem with the replacement of the specific version number involved in the version upgrade. Of course, the version does not support aarch64, and the next version will support it.
There was a problem hiding this comment.
Will scripts/release_tag.sh replace the version tags in Cargo.toml?
There was a problem hiding this comment.
Will
scripts/release_tag.shreplace the version tags in Cargo.toml?
Then maybe I need to adjust. This script automatically creates a PR after we publish it, and automatically modifies it after the PR is merged. But I know Cargo.toml needs to be modified before merging. Do I understand correctly?
There was a problem hiding this comment.
Ideal for the release flow, I think:
- Manually trigger a CI to prepare for the release. Update
Cargo.tomls, docs, and so on - We merged it
- Automatically push a new tag
- Release CI starts run by pushing a new tag.
12f838c to
695358d
Compare
|
https://github.com/cuisongliu/youki/actions/runs/6925964479 auto update version is ready @utam0k |
| - name: Version update | ||
| run: | | ||
| sudo env PATH=$PATH just version-up ${{ env.VERSION }} |
There was a problem hiding this comment.
Before running release CI, we need to update a version in Cargo.toml
There was a problem hiding this comment.
Before running release CI, we need to update a version in
Cargo.toml
Wouldn't it be better to modify it when publishing? Do we need to submit a separate PR to modify the version number?
There was a problem hiding this comment.
This script already supports automatic modification of Cargo.toml
There was a problem hiding this comment.
Who will version Cargo.toml after release? For example, create a tag v2.0.0 and push. But then the tag's branch, Cargo.toml, is not 2.0.0, is it?
There was a problem hiding this comment.
Yes, the branch is not, but the corresponding file has been changed, and pr will be automatically submitted to modify these versions later.
There was a problem hiding this comment.
I feel that the branch needs to be in a released state for later reference.
There was a problem hiding this comment.
Can't we just create a PR for the release and create a tag once it is merged?
There was a problem hiding this comment.
Of course I'd like this feature! However, I feel a little problem with the flow. The concept itself is good.
There was a problem hiding this comment.
Can't we just create a PR for the release and create a tag once it is merged?
Indeed, it‘s better to adjust the process. Just do a manual workflow.
Signed-off-by: cuisongliu <cuisongliu@qq.com>
695358d to
a3a2b2b
Compare

No description provided.