Lifei/fix GitHub workflow triggers

[lifeizhou-ap]

Why
Currently we don't have mechanism to create the version tag and publish the package for new version

What

• Enabled build on main branch
• Created a script file to check whether the version tag already exists
• Create a version tag when main branch passes the build and no same version tag exists
• When publishing the package, checkout the code with the tag version

Note
I heard we are also going to discuss the semantic version for auto version. Before the decision on the semantic version, we may use this mechanism in the PR, at least we can release new versions

[michaelneale]

should this be run on the release workflow - not ci? ci just for testing?

[lifeizhou-ap]

I can move this on the release workflow. and the release workflow depends on the ci workflow and only run on the main branch. Therefore it would be better.

because currently in my PR it shows like this (although the create tag job is skipped). It would be good to move the create tag on the release workflow.

[lifeizhou-ap]

I've pushed a commit to move the create_tag job to the pypi_release workflow now

[michaelneale]

ok to be clear, goose tells me this is how it works:

                                                                Detailed Workflow Summary:                                                                

 1 Merge to main:                                                                                                                                         
    • Upon merging a PR to the main branch, the push event triggers both workflows.                                                                       
 2 CI Workflow Execution:                                                                                                                                 
    • Build Job:                                                                                                                                          
       • The code is checked out and built.                                                                                                               
       • Tests run to ensure everything is working correctly.                                                                                             
    • Create Tag Job:                                                                                                                                     
       • The code is checked out again.                                                                                                                   
       • Required dependencies and tools are installed.                                                                                                   
       • The check_tag_exists.sh script runs:                                                                                                             
          • Extracts version number from the distribution file.                                                                                           
          • Checks if the extracted version tag already exists in the repository.                                                                         
       • Since the version hasn't changed, it detects that the version tag already exists.                                                                
       • Tag Creation:                                                                                                                                    
          • As the version tag already exists, the tag creation step is bypassed (i.e., no new tag is created).                                           
 3 PyPI Release Workflow Execution:                                                                                                                       
    • Checkout with Ref:                                                                                                                                  
       • Checks out the code with the specific reference related to the merge.                                                                            
    • Publish Step:                                                                                                                                       
       • Installs dependencies.                                                                                                                           
       • Attempts to publish the package.                                                                                                                 
       • As there’s no new version, the package will not be republished to PyPI if it already exists.                                                     

                                                                        Conclusion                                                                        

With every merge to main, the CI workflow ensures the code is built, tested, and checks for an existing version tag. If the version has not changed, it   
skips creating a new tag. Concurrently, the PyPI release workflow checks out the code and attempts to publish it, but it respects pre-existing versions,  
avoiding redundant uploads.   

is that right? that seems ok then

[lifeizhou-ap]

                                                                Detailed Workflow Summary:                                                                

 1 Merge to main:                                                                                                                                         
    • Upon merging a PR to the main branch, the push event triggers both workflows.  

The PyPI Release Workflow Execution is only triggered when a tag name starts with v is pushed

3 PyPI Release Workflow Execution:
• Checkout with Ref:
• Checks out the code with the specific reference related to the merge.

It checks out the code with the tag which was pushed

Concurrently, the PyPI release workflow checks out the code and attempts to publish it, but it respects pre-existing versions,
avoiding redundant uploads.

The Pypi release workflow does not run concurrently with the CI workflow. It is only trigged by pushing a tag name starts with v

[lifeizhou-ap]

                                                                Detailed Workflow Summary:                                                                

 1 Merge to main:                                                                                                                                         
    • Upon merging a PR to the main branch, the push event triggers both workflows.  

The PyPI Release Workflow Execution is only triggered when a tag name starts with v is pushed

3 PyPI Release Workflow Execution:
• Checkout with Ref:
• Checks out the code with the specific reference related to the merge.

It checks out the code with the tag which was pushed

Concurrently, the PyPI release workflow checks out the code and attempts to publish it, but it respects pre-existing versions,
avoiding redundant uploads.

The Pypi release workflow does not run concurrently with the CI workflow. It is only trigged by pushing a tag name starts with v

This is no long valid now. I've pushed a commit to move the create_tag job to the pypi_release workflow now

[zakiali]

Nice, I think this makes sense. However, I think initially, we probably want to manually publish tags for releases so we don't push anything broken? Or I guess the expecation is you don't version bump everything? We def need to follow up with the semver release strategy.

Also, here's a similar PR https://github.com/square/goose/pull/19/files -- I have some checks in there for checking versions in the pyproject and on pypi which maybe we just move in here?

[michaelneale]

@zakiali yeah - unless there was a goose-unstable package for people to live on the edge, but probably overkill, as long as version number changes then it could be a release? woudl be good to have more releases (of goose + exchange) regularly ig possible

[zakiali]

I think the semver/conventional commits stuff will help here greatly to have a standard practice. We can have release candidates pushed up for experimental/exploratory installs, while still having stable releases for users not wanting to be on the cutting edge. For now, releases on version bump are 👍

[michaelneale]

ok so this should have the publish only triggered on tag now? (and then check it builds of course)