You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Earlier I assumed the hash was random and unique everytime the make-json command ran. Turns out I was wrong. I didn't dig in to determine what the parameters are for the hash, but tested locally and see that they remain consistent each run (even when i18n strings are added).
This simplifies the workflow and the json files can be updated without needing a rename command (which never worked in github runner).
I'm also removing the commit step since it wasn't working either, and I'm not sure we're quite ready for it anyway. I'm just having the workflow check if there are any file changes and if so failing and echo that the composer run i18n script should be run locally to update the files if there are changes, we can disregard for small releases, but should keep it updated as best we can and can look at updating it in the future to run the command and commit the files in a release branch.
This at least brings things to a better place than an i18n step that always fails with no clear direction.
I think once we get to a place where we are ready to update this to a reusable workflow file we can figure out the commit step.
Type of Change
Bugfix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Documentation Update (if none of the other choices apply)
Also, I should note that I opened this PR against main so that the updated i18n workflow would trigger, but it was branched off release/2.8.0 so we shouldn't merge it until the release.
The module updates in the composer file are just bumping the versions to what is installed and not updating the modules - they've already been updated main, just not bumped in the composer file
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Proposed changes
Earlier I assumed the hash was random and unique everytime the make-json command ran. Turns out I was wrong. I didn't dig in to determine what the parameters are for the hash, but tested locally and see that they remain consistent each run (even when i18n strings are added).
This simplifies the workflow and the json files can be updated without needing a rename command (which never worked in github runner).
I'm also removing the commit step since it wasn't working either, and I'm not sure we're quite ready for it anyway. I'm just having the workflow check if there are any file changes and if so failing and echo that the
composer run i18nscript should be run locally to update the files if there are changes, we can disregard for small releases, but should keep it updated as best we can and can look at updating it in the future to run the command and commit the files in a release branch.This at least brings things to a better place than an i18n step that always fails with no clear direction.
I think once we get to a place where we are ready to update this to a reusable workflow file we can figure out the commit step.
Type of Change
Checklist
Further comments