ci: Automated lib version bumping #213
Conversation
scott45
changed the title
| GH_TOKEN: '${{ secrets.GH_TOKEN }}' | ||
| NODE_AUTH_TOKEN: '${{ secrets.NODE_AUTH_TOKEN }}' | ||
|
|
||
| sync-version-across-tazama-repos: |
There was a problem hiding this comment.
Can't we use dependabot instead?
There was a problem hiding this comment.
@rtkay123 is this something we're currently doing? I don't think I've seen dependabot being used for this use case but I'd like to if we're doing this.
Let us wait for what @cshezi thinks, I did have a chat with him on Friday before making these changes.
Context:
The frms-coe-lib and frms-coe-startup-lib versions don't reflect correctly in most rule processors except 901. If I also remember well, before the last release we manually created PRs to do the version bumping and all.
Briefly what these changes will do is ensure every time new versions of frms-coe-lib and frms-coe-startup-lib are published, a PR will be created in each repo that lists the lib as a dependency in package.json
There was a problem hiding this comment.
We're not currently doing that, but the change in my opinion should be in the dependabot config so that it's able to update frms-coe-lib and frms-coe-startup-lib.
There was a problem hiding this comment.
I'm going to look into this today
SPDX-License-Identifier: Apache-2.0
What did we change?
Implement automated frms-coe-lib version bumping PRs in dependent repos
Why are we doing this?
To get away with manual versions bumping
How was it tested?