-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Misc] (WIP) Automatic release pipeline #1861
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1861 +/- ##
==========================================
+ Coverage 43.23% 44.14% +0.90%
==========================================
Files 44 44
Lines 6314 6121 -193
Branches 1092 1092
==========================================
- Hits 2730 2702 -28
+ Misses 3413 3250 -163
+ Partials 171 169 -2
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
1 concern, if one of these stages fails, will the script terminate properly and allow human to take care of its rest steps manually?
Thank you so much! This will save a lot of manual work (and errors made by a human (or me)).
I need to figure out how to let Jenkins build a specific commit. Will update you tomorrow.
I think we can rely on the script for patch version bumps. Minor/Major version bumps will not happen more than once per 3 months, so it's fine to do that manually.
That sounds like a good plus, but not a must-have.
In the foreseeable future, we can simply release a new patch version in that case :-)
Right, now that folder is really a recycling center. Let's clean it up in v0.8 roadmap :-) |
Thanks, that is a really valid concern. I assume the cli will be invoked on volatile Github Actions/Jenkins worker VMs. So the short answer is that steps 1-4 will likely be executed on a cloned (or forked) repo on the VM, when any of them failed, if the developers are notified, they could jump in, fix issues and re-run the job without affecting the repo at all. (they might have to delete the branch that was pushed to remote origin in step 2) If the failure falls into steps 5-8, since they have side-effects to this remote repo, the developers will need to take over from where the ball gets dropped and continue the release. Ideally, the whole release pipeline should be a single transaction and rolls back if any of the steps fail, but I realized it's a bit hard (time-wise and potentially over-engineering) to implement as the first iteration, so I ended up implementing it as a "minimal automation that requires human beings to investigate if it goes wrong" pipeline. Also this is still WIP so suggestions are welcome! |
Thanks! Sorry, the wording might be a bit confusing, what i meant is that, if this cli is going to be invoked by Github Actions, the moment the action gets triggered, the commit hash is locked and will be used through this release so we won't be bitten by the race condition. If we are going to run this from Jenkins, yes, we need to look into how to let Jenkins build a specific commit. |
Thank you so much for everything here! Based on what you have explored, I have a few ideas to simplify the workflow: Replace Jenkins with
|
Co-authored-by: 彭于斌 <1931127624@qq.com>
Closing ancient PR. |
Related issue = #1674
[Click here for the format server]
1. The Current Release Process
Potential Problems:
2. Implementation Plan
The actual release automation shall be implemented iteratively, so the migration is more smooth.
Runs CMake to re-generate docsAS @yuanming-hu suggested, a more portable way (so the runner does not have to setup CMAKE in order to runcmake .
) is to port the logic that reads CMakeLists.txt todocs/conf.py
so it can generate and dump theversion
file on its own. Implementing it right now. (cross-referencing the functions is tricky given the unorganized nature ofmisc
directory. Since there're some refactor plans forv0.8.0
, I'm simply copy-pasting duplicate code betweenconf.py
andmisc/
for now)Waits for developers’ mergeOR waits for the builds on PR to pass and merge (this could be done via https://github.com/pascalgn/automerge-action)3. Open Questions
vMAJOR.MINOR.PATCH
?misc/
is becoming more and more like a trash bin, and barely maintained/organized, would it be more useful to refactor it to some extent, at least some code inmisc
can be re-used cross modules?Alternatives
CMAKE
before making the PR.