hi Zhenhao:
Thanks for the driving. Currently, StreamPark supports code clones and
build features similar to Jenkins. However, the code cloning feature
only supports clone code by branches and does not support clone by
tag. So, supporting clone code by tag is a great feature.
1. Change the "branches" field to "refs". When saving, add a prefix
("refs/heads/" or "refs/tags/") to distinguish the field.
2. Do not add a new field for "tags".
3. Identify whether it is a branch or a tag based on the prefix "refs/heads".
These changes will minimize alterations to the table structure.
Welcome to the discussion! I'm looking forward to hearing your views
Best,
Huajie Wang
李振豪 <li.zhen...@163.com> 于2024年8月30日周五 11:57写道：
> Hello,
>
>
> Since it is recommend by the developer guide of Streampark website, to
> make a post to this mailing lists before commit any code of new feature, I
> initiate this post. If it is unnecessary, please ignore this message.
>
>
> To whom it may concern, this is a raw proposal of "Git Tag" of Streampark
> project:
>
>
> Database table design: three available ways are:
> 1. Add a new field "tags" into table t_flink_project, store tags and
> branches separately.
> 2. Rename filed "branches" to "branch_or_tag", add prefix("refs/heads/" or
> "refs/tags/") when write this filed in order to distinguish.
> 3. Rename filed "branches" to "branch_or_tag_name", it only store the name
> of branches/tags, then add a new field "branch_or_tag_type" to distinguish.
>
>
> API design for frontend backend interaction:
> API POST /flink/project/branches, return a new format which contain both
> name and type(branch or tag). For now, it return a List<String> which only
> contain the name.
> API POST /flink/project/create and API POST /flink/project/update, add new
> field in the parameter class "project" to both save the name and
> distinguish of branches/tags. For now, it onle contains a String field
> "branches".
>
>
> That is all for the proposal, please leave comment with your suggestion.
> Thank you very much for your concern to this proposal.
>
>
> Best regards,
>
>
> Zhenhao Li
> https://github.com/lizh501
