On Wed, Feb 3, 2021 at 5:47 PM Niels Möller <[email protected]> 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
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
