ChrisTitusTech
[CI/CD] WIP: Re-use Workflows to Ensure GitHub Pages is built after every pre-release - Cleanup Workflow Naming Inconsistency - Remove 'release.yaml' workflow
Type of Change
- [x] Refactoring
- [x] CI/CD improvement
Description
This PR Fixes the close=discussion workflow not working in specific edge cases (when there's no linking to any issue or discussion, bash will crash 😅, see commit 416ab767155c2c7a40876b6af99d9d00441467c3 for the fix), and fixes createchangelog workflow which won't work in specific instances, like when you edit/delete a release, or when main branch is updated (something to do with actions/checkout action, plus how GitHub gives triggered Workflows their ref & the derived ref_name github environments/built-ins).
Besides simple fixes highlighted above, it also tries to make future deployments of winutil easier, by making use of GitHub Actions Reusable Workflows, now you can run a single workflow that'll call another workflow, and so on (up until three-layers deep (4 including the triggered workflow), source).
Diagram
Testing
As shown in latest run using these changes (link to it), it works as intended.
Fixes to close-discussion can be seen in PR https://github.com/og-mrk/winutil/pull/27 & its run (when the author of PR doesn't specify any issues/discussions), plus PR https://github.com/og-mrk/winutil/pull/28 & its run (fails because the IDs given are either not valid (not found in current repo) or simply doesn't exist, or it isn't a discussion (maybe an issue)).
The fix for createchangelog workflow is coming soon...
Impact
Makes sure that the Changelog is up-to-date with every release.
Checklist
- [x] My code adheres to the coding and style guidelines of the project.
- [x] I have performed a self-review of my own code.
- [x] I have commented my code, particularly in hard-to-understand areas.
- [ ] I have made corresponding changes to the documentation.
- [x] My changes generate no errors/warnings/merge conflicts.
could you maybe if PR #2481 gets merged first change the logics to first run the docs script, then build the docs page and in the end do the release?
could you maybe if PR #2481 gets merged first change the logics to first run the docs script, then build the docs page and in the end do the release?
Sure thing @MyDrift-user, I'll make sure to test it as well 👍
Make sure this also includes pre releases but make sure in docs it looks like a normal release to cause no issues in WinUtil.
You are doing too much with this PR... Changing the names should be its own PR. That way we can easily see what changes with the workflows. I will close this in it's current state.
Don't like the change in file name extensions as I can't analyze the difference between them well.