From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp45.i.mail.ru (smtp45.i.mail.ru [94.100.177.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 5BEAB46970E for ; Sat, 1 Feb 2020 01:53:30 +0300 (MSK) Date: Sat, 1 Feb 2020 01:53:39 +0300 From: Alexander Turenko Message-ID: <20200131225339.vrs7smcnxnyuta4a@tkn_work_nb> References: <20200130154946.57toungzdlrfup5q@tkn_work_nb> <1580446773.677687959@f326.i.mail.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1580446773.677687959@f326.i.mail.ru> Subject: Re: [Tarantool-patches] [PATCH v7] gitlab-ci: implement packing into MCS S3 List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Tikhonov Cc: Oleg Piskunov , tarantool-patches@dev.tarantool.org I looked again over the GitLab CI rules and I have a couple of questions: - What will going on if one will fork the repository and push to fork's master (or release branch) something? - What will going on if one will open a PR from a forked repository to master / release branch of our repository? - What will going on if one will open a PR from our repository branch to master / release branch of our repository? - Are there something like Travis-CI's 'cron jobs' in GitLab CI? What will going on if we'll enable it someday? I asked this, because I more or less know how Travis-CI works and I guess GitLab CI is quite similar in those points. In brief: - Travis-CI cherry-pick's commits from a source branch to a target ones for a PR (this is the difference between 'branch jobs' and 'PR jobs'). So 'PR jobs' are run like they are on a target branch. - Travis-CI does not set variables from 'Settings' (at least secret ones) for jobs in other repositories (because of security reasons). So This is applicable also for PRs to our repository from a fork. Don't sure about a PR from a branch in our repository. All those cases can be differentiated using environment variable that Travis-CI sets or by conditions in .travis.yml that can be set for a stage. So it is natural to split packaging and deployment and set specific conditions for the deployment stage. I guess we extract a deployment to a stage in GitLab CI like in Travis-CI and also set necessary conditions when it should be run. Aside of resolving forks / PRs / cron jobs problems it would also allow to don't duplicate per-distro jobs in the config, I guess. See also two comments below. WBR, Alexander Turenko. ---- > >> package: git_submodule_update > >> git clone https://github.com/packpack/packpack.git packpack > >> PACKPACK_EXTRA_DOCKER_RUN_PARAMS='--network=host' ./packpack/packpack > >> > >> +deploy: package > >> + for key in ${GPG_SECRET_KEY} ${GPG_PUBLIC_KEY} ; do \ > >> + echo $${key} | base64 -d | gpg --batch --import || true ; done > > > > I guess we need just secret key to signing. > > To use the secret key for signing it has to be imported into the user's environment. Again, why do you need a public key? Let's try to add just a secret key. If it works w/o the public one (I guess so), then remove the loop and just add the secret key. > > > >> + ./tools/update_repo.sh -o=${OS} -d=${DIST} \ > >> + -b="s3://tarantool_repo/live/${BUCKET}" build > > > >I would hide name of an S3 bucket under a CI variable. It is more about > >our infrastructure and it would be good to show less in the repo. > > S3 bucket name is opened and visible in the logs, there is no need to hide it and > to pay the attention for it, due to name is not secret at all, while the additional > secret values setup will be the dead code or additional manual steps. An S3 bucket name is part of underlying infrastructure, just like S3 compliant service we use. We should be able to replace it w/o extra commits to the repository. Let's add a variable. Hiding is not critical and is not my main point. I would however hide the variable, but up to you.