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
For example let's assume that you have a project group foo with a project foo/bar in it. You also have a project different/other in a different group. And you make foo a member of the different/other project.
Then when you get projects from group foo you will get both foo/bar and different/other...
This is problematic for gitlabform as at least when we use it and configure it to apply some config for projects within a group foo then you mean to apply it to all projects within that group and only in that group namespace (so in the example above: only foo/bar)...
For now we used skip_projects as a workaround for this, but this is too problematic at this point to keep doing that.
The text was updated successfully, but these errors were encountered:
Actually gitlabform currently assumes that all project names it gets from that API belong to given group namespace, so it results in 404 as foo/other (usually?) does not exist.
So I will fix this by only processing projects with foo namespace, so following the above example, onlyfoo/bar and it will be a safe change - it won't cause some projects which have been processed up to this point to be stopped being processed.
GitLab's API for getting projects within a project group (https://docs.gitlab.com/ce/api/groups.html#list-a-group-39-s-projects) returns also projects which are not really in the project group, but for which this group is used as a member.
For example let's assume that you have a project group
foo
with a projectfoo/bar
in it. You also have a projectdifferent/other
in adifferent
group. And you makefoo
a member of thedifferent/other
project.Then when you get projects from group
foo
you will get bothfoo/bar
anddifferent/other
...This is problematic for
gitlabform
as at least when we use it and configure it to apply some config for projects within a groupfoo
then you mean to apply it to all projects within that group and only in that group namespace (so in the example above: onlyfoo/bar
)...For now we used
skip_projects
as a workaround for this, but this is too problematic at this point to keep doing that.The text was updated successfully, but these errors were encountered: