ci: add sha256sum and version.txt

[Itsusinn]

596 #597

[Itsusinn]

@greenhat616 If you have any alternative requirement，please tell me

[greenhat616]

we might use the cargo set-version from cargo-edit to make the consistent with the version.txt? And here is the spec of semver: https://semver.org/#backusnaur-form-grammar-for-valid-semver-versions So that x.y.z-tag+buildinfo is vaild for semver.

If the program version are inconsistant with the version.txt. The updater are supposed to create a independent lockfile to fix version by file chksum, which is not implemented yet now.

Here is the mihomo alpha channel output:

Mihomo Meta alpha-3676d1b windows amd64 with go1.23.1 Wed Sep 18 14:44:10 UTC 2024
Use tags: with_gvisor

It is consistent with the content of version.txt. For manifest v1, we parsed the version, using it compare with the remote version.txt, and do the update logic.

[Itsusinn]

we might use the cargo set-version from cargo-edit to make the consistent with the version.txt?

Doing so will crate tons of commits by bot（kinda of spam i have to say）.

So no.

If the program version are inconsistant with the version.txt. The updater are supposed to create a independent lockfile to fix version by file chksum, which is not implemented yet now.

Is the program version you pointed out here meaning cli's clash-rs -v output？

If so，that's possible to do.

[greenhat616]

we might use the cargo set-version from cargo-edit to make the consistent with the version.txt?

I think we do not need to commit the changes after modify the version for alpha build, because we don't release a real alpha tag in github like other well-known repos do.

If the program version are inconsistant with the version.txt. The updater are supposed to create a independent lockfile to fix version by file chksum, which is not implemented yet now.

Is the program version you pointed out here meaning cli's clash-rs -v output？

If so，that's possible to do.

Yes

[Itsusinn]

I think we do not need to commit the changes after modify the version for alpha build, because we don't release a real alpha tag in github like other well-known repos do.

Very good thinking! But it still makes action more complex, we have to do these things in every target:

• Parse current version from Cargo.toml
• Get short SHA from git
• Install cargo-edit by cargo install (another few minutes)
• Join vars, and cargo set new-version

I would prefer add a environment called VERSION_OVERRIDE And in cli process:

let version = match env!(VERSION_OVERRIDE) {
    Some(v) -> v
    None -> env!(CARGO_PKG_VERSION)
}

Now new version (.txt) format in my mind: 0.x.y-alpha+sha.0000000

[greenhat616]

I think we do not need to commit the changes after modify the version for alpha build, because we don't release a real alpha tag in github like other well-known repos do.

Very good thinking!

Now new version (.txt) format in my mind: 0.x.y-alpha+sha.0000000

Yeah. That's enough.

[ibigbug]

Yeah let's also change the cli version output for the nightly release to make it aligned

[greenhat616]

I think we do not need to commit the changes after modify the version for alpha build, because we don't release a real alpha tag in github like other well-known repos do.

Very good thinking! But it still makes action more complex, we have to do these things in every target:

* Parse current version from `Cargo.toml`

* Get short SHA from `git`

* Install `cargo-edit` by `cargo install` (another few minutes)

* Join vars, and `cargo set new-version`

I would prefer add a environment called VERSION_OVERRIDE And in cli process:

let version = match env!(VERSION_OVERRIDE) {
    Some(v) -> v
    None -> env!(CARGO_PKG_VERSION)
}

Now new version (.txt) format in my mind: 0.x.y-alpha+sha.0000000

Yeah. If we use the cargo-edit, we'd better use cargo-binstall to install it.

And the build envs var is a good way too.

[Itsusinn]

It seems broken......