<HTML><BODY><br>Alexander, thanks for your review, I've made the changes that you suggested.<br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
Суббота, 1 января 2020, 1:53 +03:00 от Alexander Turenko <alexander.turenko@tarantool.org>:<br><br><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15805112091089468800_BODY">I looked again over the GitLab CI rules and I have a couple of<br>
questions:<br><br>
- What will going on if one will fork the repository and push to fork's<br>
master (or release branch) something?<br>
- What will going on if one will open a PR from a forked repository to<br>
master / release branch of our repository?<br>
- What will going on if one will open a PR from our repository branch to<br>
master / release branch of our repository?<br>
- Are there something like Travis-CI's 'cron jobs' in GitLab CI? What<br>
will going on if we'll enable it someday?<br><br>
I asked this, because I more or less know how Travis-CI works and I<br>
guess GitLab CI is quite similar in those points. In brief:<br><br>
- Travis-CI cherry-pick's commits from a source branch to a target ones<br>
for a PR (this is the difference between 'branch jobs' and 'PR jobs').<br>
So 'PR jobs' are run like they are on a target branch.<br><br>
- Travis-CI does not set variables from 'Settings' (at least secret<br>
ones) for jobs in other repositories (because of security reasons). So<br>
This is applicable also for PRs to our repository from a fork. Don't<br>
sure about a PR from a branch in our repository.<br><br>
All those cases can be differentiated using environment variable that<br>
Travis-CI sets or by conditions in .travis.yml that can be set for a<br>
stage. So it is natural to split packaging and deployment and set<br>
specific conditions for the deployment stage.<br><br>
I guess we extract a deployment to a stage in GitLab CI like in<br>
Travis-CI and also set necessary conditions when it should be run. Aside<br>
of resolving forks / PRs / cron jobs problems it would also allow to<br>
don't duplicate per-distro jobs in the config, I guess.<br></div></div></div></div></blockquote><p>Right, to make the jobs working correct for it I've made the changes based on the links<br>you suggested:<br></p><p><a href="https://docs.gitlab.com/ee/ci/merge_request_pipelines/#configuring-pipelines-for-merge-requests">https://docs.gitlab.com/ee/ci/merge_request_pipelines/#configuring-pipelines-for-merge-requests</a> </p><p><a href="https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/#pipelines-for-external-pull-requests">https://docs.gitlab.com/ee/ci/ci_cd_for_external_repos/#pipelines-for-external-pull-requests</a> <br><br data-mce-bogus="1"></p><p>.deploy_only_template: &deploy_only_definition<br> only:<br> - master<br> except:<br> - external_pull_requests<br> - merge_requests<br><br>.pack_only_template: &pack_only_definition<br> only:<br> - external_pull_requests<br> - merge_requests<br> - /^.*-full-ci$/<br><br>So the external_pull_requests and merge_requests will be blocked for deploying<br>and must be run for packing jobs.</p><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15805112091089468800_BODY"><br>
See also two comments below.<br><br>
WBR, Alexander Turenko.<br><br>
----<br><br>
> >> package: git_submodule_update<br>
> >> git clone <a href="https://github.com/packpack/packpack.git" target="_blank">https://github.com/packpack/packpack.git</a> packpack<br>
> >> PACKPACK_EXTRA_DOCKER_RUN_PARAMS='--network=host' ./packpack/packpack<br>
> >> <br>
> >> +deploy: package<br>
> >> + for key in ${GPG_SECRET_KEY} ${GPG_PUBLIC_KEY} ; do \<br>
> >> + echo $${key} | base64 -d | gpg --batch --import || true ; done<br>
> ><br>
> > I guess we need just secret key to signing.<br>
><br>
> To use the secret key for signing it has to be imported into the user's environment.<br><br>
Again, why do you need a public key? Let's try to add just a secret key.<br>
If it works w/o the public one (I guess so), then remove the loop and<br>
just add the secret key.</div></div></div></div></blockquote>Right, public key was not really needed - removed.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15805112091089468800_BODY"><br><br>
> ><br>
> >> + ./tools/update_repo.sh -o=${OS} -d=${DIST} \<br>
> >> + -b="s3://tarantool_repo/live/${BUCKET}" build<br>
> ><br>
> >I would hide name of an S3 bucket under a CI variable. It is more about<br>
> >our infrastructure and it would be good to show less in the repo.<br>
><br>
> S3 bucket name is opened and visible in the logs, there is no need to hide it and<br>
> to pay the attention for it, due to name is not secret at all, while the additional<br>
> secret values setup will be the dead code or additional manual steps.<br><br>
An S3 bucket name is part of underlying infrastructure, just like S3<br>
compliant service we use. We should be able to replace it w/o extra<br>
commits to the repository. Let's add a variable.<br><br>
Hiding is not critical and is not my main point. I would however hide<br>
the variable, but up to you.<br></div></div></div></div></blockquote>
Moved both bucket/dir path to Gitlab-CI variables.<br>
<br>-- <br>Alexander Tikhonov<br></BODY></HTML>