

<HTML><BODY><div class="js-helper js-readmsg-msg"><div id="style_16462412180883367219"><div id="style_16462412180883367219_BODY"><div class="cl_260644"><div>Hi!</div><div> </div><div>Thanks for the patch!</div><div>LGTM, except for comments by Sergey and a few of mine:</div><blockquote style="border-left:1px solid #0857A6;margin:10px;padding:0 0 0 10px;"><div><br>> + # We use a trick here: define the concurrency group as 'workflow<br>> + # run ID' + # 'workflow run attempt' because it is a unique<br>> + # combination for any run. So it effectively discards grouping.<br>> + #<br>> + # XXX: we cannot use `github.sha` as a unique identifier because<br>> + # pushing a tag may cancel a run that works on a branch push<br>> + # event.<br>> + group: ${{ (<br>> + github.ref == 'refs/heads/tarantool' ||<br>> + startsWith(github.ref, 'refs/heads/tarantool-')) &&<br>> + format('{0}-{1}', github.run_id, github.run_attempt) ||<br>> + format('{0}-{1}', github.workflow, github.ref) }}<br>> + cancel-in-progress: true</div></blockquote><div>IMO, it’s better to use a combination of `github.sha` + `github.event`,</div><div>since all you want is to suppress cancelation caused by tag push.</div><div>It is essentially the same, but at least it preserves the semantics.</div><blockquote style="border-left:1px solid #0857A6;margin:10px;padding:0 0 0 10px;"><div><br>So maybe we can use matrix to cover all these workflows as showing<br>here[5], using environment variables to determine setup step for the<br>particular OS (macOS or Linux)?<br><br>But maybe I am overcomplicating things, so feel free to ignore. :)</div></blockquote><div>I think that in our case it is actually better to have a lot of workflow configs.</div><div>From time to time we encounter some issues only on certain operating</div><div>systems, so it is great to have the ability to fine-tune workflow config only for</div><div>one particular OS.</div><div> </div><div>Best regards,</div><div>Maxim Kokryashkin</div><div> </div></div></div></div></div></BODY></HTML>