OSOE-735: Introduce versioning and releases #325
Conversation
…eate Workflow to automatically change refs and create a tag
WalkthroughThis update streamlines versioning and release management for GitHub Actions and Workflows. It introduces automation for setting specific references, tagging, and releasing to enhance deployment efficiency and version consistency across workflows, improving overall codebase reliability and maintainability. Changes
Assessment against linked issues
Related issues
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
…ences dev branch files
There was a problem hiding this comment.
I tested this in a fork and tagging worked great!
Question: Shouldn't workflow/action references throughout the whole repo be updated? See this commit that was triggered by the release branch and created the tag.
For example, if I use a workflow from the v1.0 tag, then it will call other workflows and actions still from the dev branch.
|
@davidpuplava just a reminder, see my review comments. |
|
Thanks @BenedekFarkas - I will look at this today |
Add inputs to tag-version workflow to pass to the set-gha-refs action. This is similar to how LGHA's spelling workflow/action is done. This then allows the tag-version-this-repo workflow to customize the additional-pattern-include-list specific to LGHA explicit references.
…c commit hash for security reasons
This comment has been minimized.
This comment has been minimized.
…re to avoid spelling action run failures
Yes, the reference should be updated in the entire repository. Let me try and replicate this by forking the repo and trying to create a release in my own remote. I'll have to check but I think this might be because it's running in a fork. But it may no longer be an issue now that the action inputs were surfaced up to the calling workflows. |
|
Ok, I believe I now have this working. I successfully created the release in my forked repo: https://github.com/davidpuplava/GitHub-Actions/releases/tag/v0.1. I had to elevate the GITHUB_TOKEN to give it |
Are the other references updating for you (= in all actions/workflows pointing to Lombiq GitHub Actions stuff)? I see the spelling dictionary prefix updating for me too in my test repo, but none of the other stuff: https://github.com/BenedekFarkas/GitHub-Actions-OSOE-735-Test/commit/ae2421a415d28c8241b58587265d0cde6c496312 |
…ralized wrapper action
No, they were not updating for me. The only reference that was updating was the spelling dictionary reference. But I did figure out what was going on. The Tag Version workflow uses a default value of the current repository's base URL as the "target" string to find called Workflows and Actions. For LGHA, this is So in our forked repositories, nothing was matched because the Set GitHub Actions References action's Set-Called-GHA-Refs.ps1 script is matching using that base URL include list (i.e. looking for To see this in action, in your repository, you can modify the Tag Version (this repo) workflow to use the called-repo-base-include-list input and pass in See an example of this in my forked copy here. I included both my repo base and LGHA repo base, and it updated all the corresponding GitHub Action calls accordingly in the automatic commit. During testing in my forked copy, I noticed a bug with the regex used to get the Git reference, which I fixed in 05a109a. I also fixed a typo in getting the line number for the matched/changed file, and I fixed in 4d5e3a8. |
Gotcha, that worked for me too, so it was PIBKAC! :D What did you to make the BTW one thing I noticed is that specifying multiple repositories via the @Piedone please check and resolve the threads above you started, if they're GTG. |
|
I checked those two in the code, looks good! |
|
Shouldn't this be merged now? |
|
Yep, we're good to go - sorry @davidpuplava for the delay. |
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
|
And here's the first release, thanks @davidpuplava! https://github.com/Lombiq/GitHub-Actions/releases/tag/v1.0 |
OSOE-735
Fixes #284
EDIT:
Adding additional information to this summary based on the feedback from coderabbitai.
Regarding the
spellingaction, I've added aadditional-pattern-include-listoption to account for special cases such as referencing files directly from the dev branch.Regarding alternate release process, the approach that we're taking here seems to be consistent with how other organizations version GitHub Actions. One difference is that well know actions such as
actions/checkoutare placed into their own repository. Considering how many different actions and workflows exist in LGHA, splitting them into different repositories is impractical, and not a very good developer experience.Explanation of this Change
The process for version LGHA is as follows:
release/v1.0where the v1.0 is which every version you want to release.release/v1.0branchrelease/v1.0and remove therelease/to get the version tagv1.0set-gha-refsthat will scan GitHub Actions and Workflows looking for@devrefs to updatev1.0reference.release/v1.0v1.0tag will be created.--forcepushed to the repo to update and existing tags that will now be outdated.Security Considerations
The new
tag-and-releaseworkflow depends on a personal access token that should be configured in a secret namedTAG_AND_RELEASE. This token is used in place of the default GITHUB_TOKEN that is typically used in workflows. The reason for this is because the token must have theworkflowpermission granted in order to push changes to GitHub Action files. By default, GITHUB_TOKEN does not have this permission.