Closed ReenigneArcher closed 11 months ago
@derberg I'm sorry for the direct mention, but is there anyway you could take a look at this?
I'm in a bind until this is resolved, or I have to manually update ~30 repos.
this is your workflow?
sorry about that, I actually did not create an updated v2
- I'm so used to using tag commit for security reason that I completely forgot
I'll refresh it
done, just rerun worflow, should be ok 🤞🏼
I recommend for security reasons to do: uses: derberg/manage-files-in-multiple-repositories@beecbe897cf5ed7f3de5a791a3f2d70102fe7c25
which is pointing to commit of given release tag
@derberg no, I'm using v2.1.0 https://github.com/LizardByte/.github/blob/25f8dee8bf0e9ad815e666d4ef7fe9afd4c2d56e/.github/workflows/global-replicator.yml#L138
It's only a dev branch right now, but that is the tag that caused the clones directory to appear.
ok, got it, the problem is here -> https://github.com/LizardByte/.github/blob/build(deps)-bummp-derberg/manage-files-in-multiple-repositories-from-v2-to-v2.1.0/.github/workflows/global-replicator.yml#L31-L48
patterns_to_include
and patterns_to_remove
are mutually exclusive
strange that below code did not work:
if (patternsToRemove && patternsToInclude) {
core.setFailed('Fields patterns_to_include and patterns_to_remove are mutually exclusive. If you want to remove files from repos then do not use patterns_to_include.');
return;
}
I am not using them together... I have two different steps.
First step does removals, second step does includes.
hmmm, these matrix are not that easy to read. ok, I see what you did there.
there are 2 options:
bot_branch_name: bot/update-files-from-global-repo
then please use workflow environmentsotherwise it is hard for me to help. I use this new version for few months already and never had such a weird issue
The matrix is equivalent to what you have. You can honestly ignore the matrix, it just runs multiple jobs instead of one... which is the same as what you're doing.
You don't have any patterns_to_remove
so perhaps the issue is related to that, I don't think it's that though...
Another thing I notice is that you don't have this action running as more than one step in any job; therefore, I think what is happening, is it's contaminating the github workspace directory... and it doesn't clean up after or between steps... based on this I will add a cleanup step to remove that directory and prevent it from matching clones/*
.
patterns_to_remove
- yeah, I don't think this is an issue either as problem is only when it funs as part of the same step
Another thing I notice is that you don't have this action running as more than one step in any job; therefore, I think what is happening, is it's contaminating the github workspace directory... and it doesn't clean up after or between steps... based on this I will add a cleanup step to remove that directory and prevent it from matching clones/*.
ah yes, makes sense, so patterns_to_remove
in separate step is not causing an issue, but after the step, clone is for sure there in the workspace, 💯 cleanup is a fix
I can confirm it works as expected after cleaning up the workspace.
I thought about just deleting the clones
directory, but ended up doing a full checkout again just to be 100% sure it's a clean github workspace.
There is an extra directory created in PRs when using v2.1.0.
I am using a matrix run, and trying to use the custom branch name option.
https://github.com/LizardByte/PyStream/pull/53/files
This is my workflow: https://github.com/LizardByte/.github/blob/25f8dee8bf0e9ad815e666d4ef7fe9afd4c2d56e/.github/workflows/global-replicator.yml#L119-L151
I'm not sure if I misconfigured something, or if this is a bug.