Improve container image tags and timestamp

[Qusic]

resolves #2477

This implementation builds for all platforms in one workflow step. I think it makes sense since all binaries are already ready at that time.
Another option is to keep using strategy matrix but we will have to upload all image manifest archives to workflow artifacts and merge them in another workflow job as demonstrated here, which seems not worth the trouble in our case. But I am open for discussion.

Currently for each release, these tags will be added for different version ranges and variations. Take v5.11.0 for example:

• v5.11.0 (no suffix for std variation)
• v5.11
• v5.11.0-extra
• v5.11-extra

Besides, if it's not marked as a prerelease, these additional tags will be added:

• v5
• latest
• v5-extra
• latest-extra

I also updated the timestamp to release creation time instead of 0. This should keep the reproducibility and make it more user-friendly to have a reasonable created time.

As for the Containerfile change, I think it's important to copy those files from an updated image, especially certificates store.

One successful test run for building job can be found here. (Pushing job failed due to permission issue)

[xiaokangwang]

I have made 2 suggests to make sure this merge request does not break design goals of the current system. I understand these changes are not easy, and it is the reason they are not implemented earlier in the first place.

Reproducibility are there to let users know the software are build from source as is without backdoor. This not only protects users from supply chain attacks from bad build machines, but also protect developers as it make sure there is no way to add a backdoor making it less attractive to pressure developers into adding backdoor into their software.

The distinction between unstable and stable release help developers to generate beta and unstable releases for user testing without the fear of major breakage of unattended systems. This significantly decrease the need to make sure a software is bug free before making an unstable release. As with all open source projects, V2Ray have limited developer resources and could not make extensive test of new features before they are released and particular depend on user testing of unstable releases to discover bugs. For this reason it is important to be able to create unstable releases that are not released to unattended systems.

[xiaokangwang]

I think it no longer support the case where a stable release is created directly, without go through unstable phase?

[Qusic]

I think it no longer support the case where a stable release is created directly, without go through unstable phase?

I tested in my fork. When promoting a prerelease to stable release by editing it, a released action will be triggered. This behavior is also documented here.

Or are you referring to those github.event.action == 'prereleased' checks I added? This is just to keep the original workflow behavior as it was only triggered by prerelease action before. So it seems to me that we never supported a stable release directly created without being a prerelease first. Please elaborate more if I misunderstand anything.

[xiaokangwang]

Or are you referring to those github.event.action == 'prereleased' checks I added? This is just to keep the original workflow behavior as it was only triggered by prerelease action before. So it seems to me that we never supported a stable release directly created without being a prerelease first. Please elaborate more if I misunderstand anything.

This will happen if a release have already been published, and a critical bug is discovered and then fixed. Such an emergency fix will not go through prerelease. This is uncommon but may happen.

[Qusic]

Or are you referring to those github.event.action == 'prereleased' checks I added? This is just to keep the original workflow behavior as it was only triggered by prerelease action before. So it seems to me that we never supported a stable release directly created without being a prerelease first. Please elaborate more if I misunderstand anything.

This will happen if a release have already been published, and a critical bug is discovered and then fixed. Such an emergency fix will not go through prerelease. This is uncommon but may happen.

Added released to triggered action list. This should work in all cases where new releases are created or the types of existing releases are changed. However, the overwrite argument is required for duplicate uploads to succeed according to the implementation.

[Qusic]

@xiaokangwang friendly ping in case you missed it. please review the latest update.

[xiaokangwang]

I didn't see any security issue with this pull request. I will merge it now and see if it work in practice. If it does create a problem, I will resolve it myself with https://github.com/estesp/manifest-tool.

[0794-8819-0610-5047]

resolves #2477

This implementation builds for all platforms in one workflow step. I think it makes sense since all binaries are already ready at that time. Another option is to keep using strategy matrix but we will have to upload all image manifest archives to workflow artifacts and merge them in another workflow job as demonstrated here, which seems not worth the trouble in our case. But I am open for discussion.

Currently for each release, these tags will be added for different version ranges and variations. Take v5.11.0 for example:

• v5.11.0 (no suffix for std variation)
• v5.11
• v5.11.0-extra
• v5.11-extra

Besides, if it's not marked as a prerelease, these additional tags will be added:

• v5
• latest
• v5-extra
• latest-extra

I also updated the timestamp to release creation time instead of 0. This should keep the reproducibility and make it more user-friendly to have a reasonable created time.

As for the Containerfile change, I think it's important to copy those files from an updated image, especially certificates store.

One successful test run for building job can be found here. (Pushing job failed due to permission issue)