feat(publisher): add tag artifacts to fileserver

[wuhuizuo]

avoid conflict with the branch objects

Signed-off-by: wuhuizuo [email protected]

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

From the pull request title and description, it seems that the changes are related to adding tag artifacts to the fileserver. The key changes in the diff are:

• The addition of the semver package to check if the version is a valid semver git tag format. If it is, then only one path is needed to store the artifacts.
• The changes to the targetFsFullPaths method to avoid conflicts with the branch objects.
• The changes to the tiup_worker method to improve error handling and logging.

There don't seem to be any potential problems with the changes. However, it would be better if the pull request description provided more context and information about why these changes were made.

As for fixing suggestions, I would recommend adding more comments to the code to explain the changes and their purpose. Additionally, providing more information in the pull request description would also be helpful.

[ti-chi-bot]

I have already done a preliminary review for you, and I hope to help you do a better job.

Based on the pull request title and description, the key changes being made are adding tag artifacts to the fileserver and avoiding conflicts with the branch objects. The changes are made to the Dockerfile, go.mod, funcs_fs.go, funcs_fs_test.go, tiup_worker.go, and tiup_worker_test.go files.

However, there is not enough context provided to fully understand the changes and their impact. It would be helpful to have more information on why these changes were made and what problem they are solving.

In terms of potential problems, there are no obvious issues in the diff provided. However, it is possible that the changes could cause unforeseen issues elsewhere in the codebase.

As for fixing suggestions, it would be helpful to have more information on the context and reasoning behind the changes. Without that information, it is difficult to provide specific suggestions for improvement. However, it is always a good practice to thoroughly test changes before pushing them to production and to ensure that they do not cause conflicts with other parts of the codebase.

[wuhuizuo]

/approve

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wuhuizuo

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [wuhuizuo]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment