chore: Migrate CI & CD to GitHub Actions

[LeeDongGeon1996]

Description

• Migrate CI & CD to GitHub Actions

Fixes #319

Checklist

• My code follows the existing style, code structure, and naming taxonomy
• I have commented my code, particularly in hard-to-understand areas
• I have performed a self-review of my own code and included any verifying manual calculations
• I have added or updated unit tests that prove my fix is effective or that my feature works, and achieves sufficient code coverage. New and existing unit tests pass locally and in the build (below) with my changes
• My changes generate no new warnings and running code analysis does not produce any issues
• I have added or run the performance tests that depict optimal execution times
• I have made corresponding changes to the documentation

[LeeDongGeon1996]

GPT did it all...👍

[LeeDongGeon1996]

@DaveSkender Can you check Azure Pipelines webhook config? It's staying on pending status.

And are we going to keep using gitversion for deploying? or we can just tag and use tag as a package version.
I configured that it can detect semver from git tag using setuptool_scm.

I'm following this guide(Publishing package distribution releases using GitHub Actions CI/CD workflows) and it uses PyPI’s trusted publishing, Can you config for it?
Also, it will be great if we can set deployment protection rules.

[DaveSkender]

I've added the Trusted Publisher Management for two new environments pypi and pypi-test. The former requires my review; whereas the later should be a bit more open for action.

[DaveSkender]

Also, check for an equivalent auto-draft for the release notes after successful publish to pypi environment, same or similar to:

https://github.com/DaveSkender/Stock.Indicators/blob/6c70e30eff7e9b8bbd0e37a3fbf006e585346b34/.github/workflows/deploy-package.yml#L157-L167

Note: this may need to be configured slightly different if the timing of tagging is different. I didn't think through the scenario, so it may be okay with same implementation.

[DaveSkender]

I've also removed the required check for the Azure Pipelines build, but will need to add the new CI.yml variant to the branch protection rules once everything's working well here, and probably after this is merged.

[LeeDongGeon1996]

@DaveSkender Thanks for your work :)

The former requires my review; whereas the later should be a bit more open for action.

Yeah, that's why we need to set deployment protection rules or add review step before deployment

[DaveSkender]

I really only have one question, how is the release tag introduced on main?

[DaveSkender]

Also, we'd need to pull out the unused SemVer stuff like gitversion.yml, how its written in contributing.md, and any other integrations that might exist in setup.py or other places where the version number is stamped.

[DaveSkender]

How does the test.pypi.org publish get its version number?

[LeeDongGeon1996]

You're right! I'll draft fixed contributing.md and then you correct that please.

[LeeDongGeon1996]

setuptools_scm does everything. It recognize the latest tag on repository. (AFAIK, it uses git describe)

If it's not incrementing a pre-release suffix, the publish will get rejected as a duplicate when you commit 2+ times to main before introducing an actual new Tag. If it doesn't auto-increment, you can always add a x.x.x.{ github.run_id } or something like that on it, if feasible.

(oops, sorry, edited your comment accidentally)

[LeeDongGeon1996]

Yeah as I know, setuptool_scm resolve that problem by creating unique version number, let me double check.

---

I've just checked that it creates unique version number by every new commit.

[DaveSkender]

Let me know when you're done with contributing.md and I'll take an editorial pass on it.

[LeeDongGeon1996]

Yeah, I've already done!
You can merge after work is done.

[DaveSkender]

All good on my end. Merge when ready.