In a self-managed deployment, with the admin mode restriction, if an admin configures a pipeline schedule, but is not a member of the project, the pipeline is not triggered.
N/A on gitlab.com
The pipeline is not triggered, although the UI says that it would be.
Either refuse the schedule creation to the admin not being member of the project, or send an error when the pipeline fails to be triggered.
2022-10-18T13:03:03.324Z pid=19 tid=6e7r class=ExternalServiceReactiveCachingWorker jid=758cd59a7c650a7b706cdd8c INFO: start 2022-10-18T13:03:03.326Z pid=19 tid=6e7r class=ExternalServiceReactiveCachingWorker jid=758cd59a7c650a7b706cdd8c INFO: arguments: ["VersionCheck","15.4.2"] 2022-10-18T13:03:03.328Z: AdminMode::Server bypasses session for admin mode in job: {"retry"=>3, "queue"=>"default", "version"=>0, "class"=>"ExternalServiceReactiveCachingWorker", "args"=>["VersionCheck", "15.4.2"], "jid"=>"758cd59a7c650a7b706cdd8c", "created_at"=>1666098119.3366916, "correlation_id"=>"e688733e9d7e203e5e09e67483a5295b", "meta.caller_id"=>"ExternalServiceReactiveCachingWorker", "meta.remote_ip"=>"10.42.13.89", "meta.feature_category"=>"not_owned", "meta.user"=>"cdr", "meta.client_id"=>"user/4", "meta.related_class"=>"VersionCheck", "meta.root_caller_id"=>"Admin::VersionCheckController#version_check", "worker_data_consistency"=>"always", "admin_mode_user_id"=>4, "size_limiter"=>"validated", "scheduled_at"=>1666098179.3366275, "idempotency_key"=>"resque:gitlab:duplicate:default:498d77fc26c0226348c52245821cf6fdcd857a515ce2546dac22bdb24a9d04b7", "enqueued_at"=>1666098183.322755} {"severity":"DEBUG","time":"2022-10-18T13:03:03.328Z","correlation_id":"e688733e9d7e203e5e09e67483a5295b","message":"AdminMode::Server bypasses session for admin mode in job: {\"retry\"=\u003e3, \"queue\"=\u003e\"default\", \"version\"=\u003e0, \"class\"=\u003e\"ExternalServiceReactiveCachingWorker\", \"args\"=\u003e[\"VersionCheck\", \"15.4.2\"], \"jid\"=\u003e\"758cd59a7c650a7b706cdd8c\", \"created_at\"=\u003e1666098119.3366916, \"correlation_id\"=\u003e\"e688733e9d7e203e5e09e67483a5295b\", \"meta.caller_id\"=\u003e\"ExternalServiceReactiveCachingWorker\", \"meta.remote_ip\"=\u003e\"10.42.13.89\", \"meta.feature_category\"=\u003e\"not_owned\", \"meta.user\"=\u003e\"cdr\", \"meta.client_id\"=\u003e\"user/4\", \"meta.related_class\"=\u003e\"VersionCheck\", \"meta.root_caller_id\"=\u003e\"Admin::VersionCheckController#version_check\", \"worker_data_consistency\"=\u003e\"always\", \"admin_mode_user_id\"=\u003e4, \"size_limiter\"=\u003e\"validated\", \"scheduled_at\"=\u003e1666098179.3366275, \"idempotency_key\"=\u003e\"resque:gitlab:duplicate:default:498d77fc26c0226348c52245821cf6fdcd857a515ce2546dac22bdb24a9d04b7\", \"enqueued_at\"=\u003e1666098183.322755}"} 2022-10-18T13:03:03.780Z pid=19 tid=6e7r class=ExternalServiceReactiveCachingWorker jid=758cd59a7c650a7b706cdd8c WARN: Job arguments to ExternalServiceReactiveCachingWorker do not serialize to JSON safely. This will raise an error in 2022-10-18T13:03:03.789Z pid=19 tid=6e7r class=ExternalServiceReactiveCachingWorker jid=758cd59a7c650a7b706cdd8c elapsed=0.464 INFO: done
System information System: Current User: git Using RVM: no Ruby Version: 2.7.5p203 Gem Version: 3.2.33 Bundler Version:2.3.15 Rake Version: 13.0.6 Redis Version: 6.0.16 Sidekiq Version:6.4.2 Go Version: unknown GitLab information Version: 15.4.2 Revision: ef309cf1466 Directory: /srv/gitlab DB Adapter: PostgreSQL DB Version: 13.8 URL: https://gitlab.antemeta.io HTTP Clone URL: https://gitlab.antemeta.io/some-group/some-project.git SSH Clone URL: git@gitlab.antemeta.io:some-group/some-project.git Using LDAP: yes Using Omniauth: no GitLab Shell Version: 14.10.0 Repository storage paths: - default: /var/opt/gitlab/repo GitLab Shell path: /home/git/gitlab-shell
Not sure the errors are expected or not on a kubernetes helm deployment. We do have pods for gitlab-shell and sidekiq, and of course there is no systemd nor init script.
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 14.10.0 ? ... OK (14.10.0) Running /home/git/gitlab-shell/bin/check gitlab-shell self-check failed Try fixing it: Make sure GitLab is running; Check the gitlab-shell configuration file: sudo -u git -H editor /home/git/gitlab-shell/config.yml Please fix the error above and rerun the checks.
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... no Try fixing it: sudo -u git -H RAILS_ENV=production bin/background_jobs start For more information see: doc/install/installation.md in section "Install Init Script" see log/sidekiq.log for possible errors Please fix the error above and rerun the checks.
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain LDAP authentication... Success LDAP users with access to your GitLab server (only showing the first 100 results) User output sanitized. Found 100 users of 100 limit.
Checking LDAP ... Finished
Checking GitLab App ...
Database config exists? ... yes All migrations up? ... yes Database contains orphaned GroupMembers? ... no GitLab config exists? ... yes GitLab config up to date? ... yes Log directory writable? ... yes Tmp directory writable? ... yes Uploads directory exists? ... yes Uploads directory has correct permissions? ... yes Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet) Systemd unit files or init script exist? ... no Try fixing it: Install the Service For more information see: doc/install/installation.md in section "Install the Service" Please fix the error above and rerun the checks. Systemd unit files or init script up-to-date? ... can't check because of previous errors Projects have namespace: ... 48/22 ... yes 50/23 ... yes 50/24 ... yes 53/25 ... yes 53/26 ... yes 53/27 ... yes 61/28 ... yes 50/29 ... yes 50/31 ... yes 56/33 ... yes 50/34 ... yes 51/35 ... yes 56/36 ... yes 56/37 ... yes 50/39 ... yes 53/41 ... yes 55/42 ... yes 56/43 ... yes 56/44 ... yes 51/45 ... yes 61/46 ... yes 50/47 ... yes 50/48 ... yes 49/49 ... yes 56/50 ... yes 61/51 ... yes 56/52 ... yes 56/53 ... yes 51/54 ... yes 63/56 ... yes 51/57 ... yes 63/58 ... yes 55/59 ... yes 55/60 ... yes 55/61 ... yes 56/62 ... yes 19/63 ... yes 50/65 ... yes 53/66 ... yes 55/67 ... yes 52/68 ... yes 61/69 ... yes 61/70 ... yes 58/71 ... yes 50/72 ... yes 51/73 ... yes 51/74 ... yes 51/75 ... yes 51/76 ... yes 5/77 ... yes 51/78 ... yes 53/79 ... yes 53/80 ... yes 5/81 ... yes 68/82 ... yes 63/83 ... yes 55/84 ... yes 3/86 ... yes 50/87 ... yes 2/88 ... yes 69/89 ... yes 61/90 ... yes 61/91 ... yes 109/93 ... yes 109/94 ... yes 19/95 ... yes 55/96 ... yes 69/97 ... yes 61/98 ... yes 50/99 ... yes 55/100 ... yes 2/102 ... yes 2/103 ... yes 2/104 ... yes 2/105 ... yes 50/106 ... yes 61/107 ... yes 5/108 ... yes 109/109 ... yes 5/110 ... yes 5/111 ... yes 5/112 ... yes 5/113 ... yes 76/115 ... yes 61/117 ... yes 2/118 ... yes 51/119 ... yes 76/120 ... yes 50/121 ... yes 67/122 ... yes 50/123 ... yes 58/124 ... yes 50/125 ... yes 3/128 ... yes 65/129 ... yes 63/130 ... yes 51/131 ... yes 175/132 ... yes 56/133 ... yes 56/134 ... yes 56/135 ... yes 50/136 ... yes 58/138 ... yes 108/140 ... yes 69/141 ... yes 51/142 ... yes 5/143 ... yes 95/145 ... yes 95/147 ... yes 53/148 ... yes 50/149 ... yes 89/153 ... yes 95/154 ... yes 95/155 ... yes 101/156 ... yes 102/157 ... yes 102/158 ... yes 102/159 ... yes 102/160 ... yes 61/162 ... yes 68/163 ... yes 56/165 ... yes 56/166 ... yes 106/169 ... yes 19/170 ... yes 50/172 ... yes 51/173 ... yes 59/174 ... yes 89/175 ... yes 55/176 ... yes 53/177 ... yes 68/178 ... yes 67/179 ... yes 109/180 ... yes 95/181 ... yes 50/182 ... yes 63/183 ... yes 19/184 ... yes 51/185 ... yes 68/186 ... yes 108/187 ... yes 67/188 ... yes 68/189 ... yes 19/190 ... yes 89/191 ... yes 95/192 ... yes 95/193 ... yes 95/194 ... yes 95/195 ... yes 95/196 ... yes 95/197 ... yes 113/198 ... yes 113/199 ... yes 113/200 ... yes 113/202 ... yes 113/203 ... yes 108/204 ... yes 108/205 ... yes 108/206 ... yes 108/207 ... yes 108/208 ... yes 51/209 ... yes 34/210 ... yes 101/211 ... yes 34/212 ... yes 19/213 ... yes 19/214 ... yes 63/216 ... yes 95/217 ... yes 68/218 ... yes 117/220 ... yes 117/221 ... yes 117/222 ... yes 51/223 ... yes 118/224 ... yes 51/225 ... yes 34/226 ... yes 51/227 ... yes 51/228 ... yes 101/229 ... yes 112/230 ... yes 53/232 ... yes 95/234 ... yes 68/235 ... yes 53/236 ... yes 3/237 ... yes 19/238 ... yes 121/239 ... yes 118/240 ... yes 95/241 ... yes 67/242 ... yes 68/243 ... yes 50/244 ... yes 5/245 ... yes 53/246 ... yes 120/247 ... yes 19/248 ... yes 5/249 ... yes 34/250 ... yes 95/251 ... yes 118/252 ... yes 68/253 ... yes 68/254 ... yes 50/255 ... yes 63/257 ... yes 5/258 ... yes 59/259 ... yes 51/260 ... yes 108/262 ... yes 112/263 ... yes 112/264 ... yes 108/265 ... yes 51/266 ... yes 108/267 ... yes 112/268 ... yes 125/269 ... yes 125/270 ... yes 51/271 ... yes 5/272 ... yes 61/273 ... yes 5/274 ... yes 118/275 ... yes 128/276 ... yes 50/277 ... yes 128/278 ... yes 118/279 ... yes 128/280 ... yes 108/281 ... yes 120/282 ... yes 118/283 ... yes 108/285 ... yes 50/286 ... yes 50/287 ... yes 5/288 ... yes 34/289 ... yes 129/290 ... yes 118/291 ... yes 118/292 ... yes 118/293 ... yes 118/294 ... yes 120/295 ... yes 118/296 ... yes 118/297 ... yes 118/298 ... yes 120/299 ... yes 19/300 ... yes 61/301 ... yes 120/302 ... yes 89/303 ... yes 68/304 ... yes 5/305 ... yes 120/306 ... yes 120/307 ... yes 59/308 ... yes 59/309 ... yes 50/310 ... yes 143/311 ... yes 95/312 ... yes 50/313 ... yes 143/314 ... yes 120/315 ... yes 95/316 ... yes 50/317 ... yes 144/318 ... yes 120/319 ... yes 68/320 ... yes 61/321 ... yes 120/322 ... yes 143/324 ... yes 150/329 ... yes 150/330 ... yes 150/331 ... yes 150/332 ... yes 108/333 ... yes 144/335 ... yes 120/336 ... yes 5/337 ... yes 150/339 ... yes 50/340 ... yes 34/341 ... yes 19/342 ... yes 95/343 ... yes 108/345 ... yes 150/346 ... yes 158/347 ... yes 2/348 ... yes 120/349 ... yes 95/351 ... yes 61/352 ... yes 53/353 ... yes 108/354 ... yes 34/355 ... yes 120/356 ... yes 163/357 ... yes 50/358 ... yes 95/359 ... yes 167/360 ... yes 121/361 ... yes 121/362 ... yes 121/363 ... yes 34/364 ... yes 50/365 ... yes 61/366 ... yes 120/367 ... yes 120/368 ... yes 167/369 ... yes 171/370 ... yes 175/371 ... yes 175/372 ... yes 175/373 ... yes 120/374 ... yes 181/375 ... yes 496/376 ... yes 496/377 ... yes 108/378 ... yes 496/379 ... yes Redis version >= 6.0.0? ... yes Ruby version >= 2.7.2 ? ... yes (2.7.5) Git user has default SSH configuration? ... yes Active users: ... 60 Is authorized keys file accessible? ... skipped (authorized keys not enabled) GitLab configured to store new projects in hashed storage? ... yes All projects are in hashed storage? ... yes
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
This is still happening on gitlab.com next. See dr4Ke/gitlab-issue-example#4 (comment 712616681) where I added these two action lines:
/spend 8h 2021-10-20
/spend 4h30m 2021-10-21
And only the latter is added to the total spent time (4h40 now)
Entered:
/spend 8h 2021-10-20
/spend 4h30m 2021-10-21
When using the --export-session
, the session cookies are saved. It would be nice if they could be used at the next execution if they are still valid.
Wouldn't it be nice if we could declare complex variables in .gitlab-ci.yml
that would be available as json strings (or some other format) in environment variables?
We could use this syntax:
variables:
MYLIST:
- item1
- item2
MYMAP:
key1: val1
key2: val2
MYSTRING: |
line1
line2
The resulting environment variables would be:
MYLIST='["item1","item2"]'
MYMAP='{"key1":"val1","key2":"val2"}'
MYSTRING="line1\nline2"
I suppose a simple yaml->json
conversion would work, and be backward compatible.
Christophe Drevet (a406dc5a) at 14 Dec 14:04
Update .gitlab-ci.yml
Christophe Drevet (901c2d51) at 14 Dec 14:02
Update .gitlab-ci.yml
Christophe Drevet (5dd91ff1) at 14 Dec 14:00
Update .gitlab-ci.yml
Christophe Drevet (777de988) at 14 Dec 13:59
May be related to #245257 (closed)
I can confirm this issue is still there on the latest version of gitlab, even on gitlab.com.
I've commented two lines on dr4Ke/gitlab-issue-example#4:
/spend 20m 2020-10-18
/spend 10m 2020-10-19
It results in only one hour total count. However, the temporary comment shows both entries.
My issue was solved by removing the add-on, closing Firefox, then reinstalling the add-on.
Thanks for the quick fix. Though I'm still facing some similar error after a normal update to the 4.5.1 version.
This time, this is:
Error
null is not a valid string
My log seems empty and the Delete
button is greyed out. I set 0 days of history and the error disappear. If I put it back to 7 days, the error comes back.
Now, I'll try to uninstall/reinstall and… it's all the same. This issue doesn't happen on a fresh firefox profile.
As a somewhat long time git user now, I'm used to the git diff
command that gives me the differences between a ref and another, regardless of history.
Gitlab compare and merge request changes use another way. They display changes between the source branch and the last common commit. This has several impacts:
ref1
vs ref2
" is not the opposite of a "compare ref2
vs ref1
".Example in the dr4Ke/gitlab-issue-example> project.
This is the history graph:
Comparing branch1
and master
with git diff
gives me:
$ git diff master..branch1
diff --git a/README.md b/README.md
index f3287c7..d42096b 100644
--- a/README.md
+++ b/README.md
@@ -1 +1,3 @@
-This is a README for a different issue.
+This is a new issue.
+
+Some more doc.
$ git diff branch1..master
diff --git a/README.md b/README.md
index d42096b..f3287c7 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1 @@
-This is a new issue.
-
-Some more doc.
+This is a README for a different issue.
We can see the second is the opposite of the first.
Now gitlab branch comparison gives me this:
We see that one is not the opposite of the other. And it's also not what would happen if I merge branch1
into master
.
I consider the compare function of gitlab more as a "history diff" than a "code diff".
I don't understand why we would want to see changes between an old target branch and the source branch rather than the current target and the source. I didn't find something explaining this behavior in past issues (but there are many and I may have missed it) or in the documentation.
Christophe Drevet (777de988) at 11 Sep 10:29
new issue
I'll do it on this issue, it will be fun.
I can't add time spent on this issue. Too bad.
The time tracking loose spent time if the originated comment is removed.
I discovered this by mistake: I had mispelled /spend
in a comment and wanted to correct it afterwards. Then the comment was empty, besides the tracking, and an error appeared when saving the modified comment. When I refreshed the page, there was a note telling I added 1h of time spent, but no change in the issue time tracking amount. This led me to investigate a bit.
A comment.
/spend 1h
1h
None
, even though the added 1h of time spent
note is still there
No need to, I think.
The time tracking is lost if the originated message is deleted.
The time tracking should stay OK. As we don't see the /spend 1h
in the comments, we don't know it is there before we delete the comment.
This bug happens on GitLab.com.