-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. Weβll occasionally send you account related emails.
Already on GitHub? Sign in to your account
problems with setting variables which already exist (idempotence) with gitlabform 2.10.1 #354
Comments
Hi @weakcamel! I tested it on gitlabform 2.10.0 + GitLab 14.8.5-ee, gitlabform 2.10.1 + GitLab 14.2.4-ee and gitlabform 2.10.1 + GitLab 13.12.15-ee and I wasn't able to reproduce it. |
Can you please retry with the latest pre-release version, enable debug mode and share the output, @weakcamel? Note: please check that output for secrets before sharing! |
Hello, Sorry for late reply, I've been away for a couple of days. Interesting that it doesn't always reproduce.. hmm...
|
Installed the latest version from
and the output (redacted) is
|
Thanks. It's super strange this output shows that there is no Perhaps you have Update: I did a test with instance-level variable and if it is set it DOES NOT cause error like above for me. But as I don't have any other ideas I would appreciate if you can test at least this... |
I thought it might be a conflict between group and project vars but it's not that either - the project doesn't have any variables at all. Another thought though: there are quite a few variables (30). Perhaps the response gets paginated by Gitlab and there are other pages to be processed? Update: indeed, when I ran a curl with
I could see all the variables whereas without |
as it happened a few times already that we didn't mark an API as using pagination initially and it caused problems for some users. According to GitLab's API docs (https://docs.gitlab.com/ee/api/#pagination) the pagination "is available on all endpoints", so let's just pass the for all GETs. Fixes #354.
Congrats and thanks for debugging this successfully @weakcamel. ππ I plan to merge the above MR and release a patch release after the weekend. (Technically this is a bugfix but some people's gitlabform runs may behave differently after we apply it and I try to follow the principle of least astonishment - especially during the weekend. π) |
as it happened a few times already that we didn't mark an API as using pagination initially and it caused problems for some users. According to GitLab's API docs (https://docs.gitlab.com/ee/api/#pagination) the pagination "is available on all endpoints", so let's just pass the for all GETs. Fixes #354.
I have released the fix in v2.11.0b2 but it would take me some time to release v2.10.2 with this thing too though. Can you temporarily switch to using the latest pre-release or exactly v2.11.0b2, @weakcamel, and verify if it works for you? I expect a final release of v2.11.0 to happen within a few days. |
That's fantastic @gdubicki , many thanks! I tried the v2.11.0b2 release and it worked like a charm. |
The fix is now in a final release v2.11.0. |
Describe the bug
This issue appeared when I bumped gitlabform from 2.8.1 to 2.10.1 (also visible in 2.10.0)
If I delete the group variable, this call adds it back but fails on re-run.
GitLabForm version
Output of
gitlabform -V
GitLab version
13.12.15-ee
The text was updated successfully, but these errors were encountered: