On Wed, Feb 3, 2021 at 5:47 PM Niels Möller nisse@lysator.liu.se wrote:
It looks like this hardcodes the branch to test ("s390x"), while the ci jobs usually runs on all branches. It also doesn't clean up the remote state between builds.
I wonder if it would be more reliable to run make dist PACKAGE_VERSION=snapshot on the ci build machine, and copy the resulting tarball to the remote machine for build and test. The commands run on the remote machine should unpack the snapshot in a fresh directory, run configure, make, make check.
I figured an approach that test the branch in which the changes are committed:
Debian.remote.s390x: image: $CI_REGISTRY/$BUILD_IMAGES_PROJECT:$DEBIAN_BUILD before_script: - apt-get update -qq - apt-get install -qq git - 'which ssh-agent || ( apt-get install -qq openssh-client )' - eval $(ssh-agent -s) - ssh-add <(echo "$SSH_PRIVATE_KEY") - mkdir -p ~/.ssh - echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config - ssh linux1@IP_ADDRESS "mkdir -p nettle_ci/$CI_PIPELINE_IID" script: - ssh linux1@IP_ADDRESS "cd nettle_ci/$CI_PIPELINE_IID && git clone --depth=1 --branch $CI_COMMIT_REF_NAME https://gitlab.com/gnutls/nettle.git . && ./.bootstrap && ./configure --disable-documentation && make && make check" after_script: - eval $(ssh-agent -s) - ssh-add <(echo "$SSH_PRIVATE_KEY") - ssh linux1@IP_ADDRESS "rm -rf nettle_ci/$CI_PIPELINE_IID/ && exit" tags: - shared - linux except: - tags
It used CI_PIPELINE_IID to make a new directory with a unique name to safely handle job race conditions in case pushing many commits quickly. According to https://docs.gitlab.com/ee/ci/variables/predefined_variables.html CI_PIPELINE_IID is unique for the current project so it's ok to use it in this context. After the job is completed, the directory with a unique name is removed for cleaning up. However, this approach has a downside, if more than one commit is pushed quickly, all the created pipelines may check the latest commit, not the corresponding ones. We can solve this issue by using CI_COMMIT_SHA predefined environment variable and commands like git reset --hard $CI_COMMIT_SHA or git checkout $CI_COMMIT_SHA. However, I haven't tested any and am not sure if it's worth it.
Maamoun's suggested method was to add it as a "Variable" in the CI/CD
web config, I'm assuming that will not make it publicly visible (but I'd need to double check).
It looks like it doesn't expose the key publicly, it shows $SSH_PRIVATE_KEY name in the console windows without revealing any value, not sure if there other places where such things could be exploited or something.
regards, Mamone