Add ARM64 jobs in Travis-CI

[odidev]

• Added ARM64 jobs in Travis-CI
• Updated global variables in scripts travis_test.sh and travis_prepare.sh

Signed-off-by: odidev odidev@puresoftware.com

[odidev]

@dvarrazzo,

Added test variables as global variables and removed python 3.4 as it is not available in dist bionic.

[dvarrazzo]

You don't like a double negative I see? 😄

[odidev]

By default TEST_PAST=1, May I know where we are setting this?

If we set there TEST_PAST=0, no need to add extra global variables.

[dvarrazzo]

They are in travis ci: more options (top right) -> settings.

You should have all of them, except the protected ones. But maybe you don't and you need them?

The way they were defined was so that they do a reasonable thing if you have them all to 0, hence the negative to test the present. Do you think it's too awkward? We can set TEST_PRESENT=1 in the defaults.

Honestly I would make this even more robust by using the -u switch in the bash script so that the script fails in case of undefined variable, and set the sensible default into the script in order to be explicit in what is its default behaviour and what can be overridden.

What do you think?

[odidev]

They are in travis ci: more options (top right) -> settings.

I think only you can set them. I am not able to see them.

You should have all of them, except the protected ones. But maybe you don't and you need them?

Having all of them sounds good.

The way they were defined was so that they do a reasonable thing if you have them all to 0, hence the negative to test the present. Do you think it's too awkward? We can set TEST_PRESENT=1 in the defaults.

Please use TEST_PRESENT=1 as it looks better than testing with a double negative.

Honestly I would make this even more robust by using the -u switch in the bash script so that the script fails in case of undefined variable, and set the sensible default into the script in order to be explicit in what is its default behaviour and what can be overridden.

Yes, we can make setting of these variables mandatory.

[dvarrazzo]

In this case probably the script was working by relying that whatever wasn't set was equivalent to 0. It's not the way I wrote bash scripts nowadays, I got a bit stricter.

What I would like to see is the script running with set -u (throwing errors if a variable is undefined) and having those 5 variables defined inside the script with a pattern of "set them to '0' if they are undefined", which I think you can obtain with something like

export TEST_PAST=${TEST_PAST:-0}

and TEST_PRESENT, defaulting to 1, replacing the double negative one.

To organise: is it something you can try to do or do you want me to do it? It may take me some time to be able to jump on this task though.

[odidev]

I have added it to the global variables section in travis.yml. It is not working as expected if we add them in travis_prepare.sh and travis_test.sh. Tests will pass once you set TEST_PAST=0 in Travis-CI settings or remove the variables from Travis-CI settings. Please check the local build report for confirmation on test execution.

[dvarrazzo]

In this case probably the script was working by relying that whatever wasn't set was equivalent to 0. It's not the way I wrote bash scripts nowadays, I got a bit stricter.

What I would like to see is the script running with set -u (throwing errors if a variable is undefined) and having those 5 variables defined inside the script with a pattern of "set them to '0' if they are undefined", which I think you can obtain with something like

export TEST_PAST=${TEST_PAST:-0}

and TEST_PRESENT, defaulting to 1, replacing the double negative one.

To organise: is it something you can try to do or do you want me to do it? It may take me some time to be able to jump on this task though.

[dvarrazzo]

Hey hello,

I fished back this MR and noticed that now Travis works and the ARM tests passed.

I had a few comments and never submitted my comments, so I can't remember precisely the state we left this work.

Would you like to check if some of the comments are still applicable? I'll try and merge the MR, and leave it in unless Travis starts behaving funny again.

Thank you very much for your contribution!

[dvarrazzo]

This matrix definition is curious, but it seems doing the right job. Do I undestand correctly that the python and the arch sections are multiplied, and the matrix section is added afterwards?

[odidev]

I agree with your analysis that the python and the arch sections are multiplied, and the matrix section is added afterwards

[dvarrazzo]

I'm not exactly in love with this version (3.4), I'm pretty sure it's out of use, but if it doesn't cause you problem I prefer it remains in the test grid, and to remove it in the next major version

[odidev]

I have tried adding python3.4 for AMD64 but it is failing with below error

$ curl -sSf --retry 5 -o python-3.4.tar.bz2 ${archive_url}
curl: (22) The requested URL returned error: 404 
Unable to download 3.4 archive. The archive may not exist. Please consider a different version.

It seems the Travis doesn't support python3.4 for AMD64 also.

[dvarrazzo]

I am not sure this work these way in the travis config: this syntax is meant to be for the bash script. My idea is that if the variables are set in the travis environment then the script would use them, otherwise the script may have a sensible, but explicit default, to make it test the right stuff (i.e. only the present versions).

[odidev]

I have added variable declaration in scripts. Please check and let me know.

[dvarrazzo]

Ok, I would say this MR is doing its job: ARM gets tested and AMD64 isn't broken, so I guess it's good.

If there will be build/test problems in the future I'll deal with them. Of course if there are problems with the ARM build I'll bother you, @odidev ;)

Thank you for your contribution!