-
Notifications
You must be signed in to change notification settings - Fork 356
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
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 :-)
docs/src/user/basic_setup.md
Outdated
@@ -47,11 +47,11 @@ Install from the GitHub release. | |||
Note that this way also requires the aforementioned installation. | |||
|
|||
```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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 |
docs/src/user/basic_setup.md
Outdated
```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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]>
8d2c2e8
to
d65d383
Compare
Signed-off-by: cuisongliu <[email protected]>
this pr is ready @utam0k |
justfile
Outdated
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why can we delete them? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will scripts/release_tag.sh
replace the version tags in Cargo.toml?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will
scripts/release_tag.sh
replace 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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideal for the release flow, I think:
- Manually trigger a CI to prepare for the release. Update
Cargo.toml
s, 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 |
.github/workflows/release.yml
Outdated
- name: Version update | ||
run: | | ||
sudo env PATH=$PATH just version-up ${{ env.VERSION }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Before running release CI, we need to update a version in Cargo.toml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This script already supports automatic modification of Cargo.toml
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel that the branch needs to be in a released state for later reference.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 <[email protected]>
695358d
to
a3a2b2b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works fine! Thanks 😍
No description provided.