Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

Redo docker readme #2040

Merged
merged 5 commits into from
Jun 5, 2018
Merged

Conversation

ingwinlu
Copy link
Contributor

@ingwinlu ingwinlu commented Jun 4, 2018

Purpose

Redo the README.md and bring it up to date with the new Docker images. Also move the old README.md and related files into a legacy directory.

Checklist

Check relevant points but please do not remove entries.
For docu fixes, spell checking, and similar nothing
needs to be checked.

  • commit messages are fine ("module: short statement" syntax and refer to issues)
  • affected documentation is fixed
  • release notes are updated (doc/news/_preparation_next_release.md)

@markus2330 please review my pull request

Copy link
Contributor

@markus2330 markus2330 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works perfectly! This fills a huge gap in the documentation, thank you!

Only small remarks here.

- abort of previously queued but unfinished runs on new commits
- Better Docker image handling.
- Abort of previously queued but unfinished runs on new commits.
- Document how to locally replicate the Docker environment used for tests.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please add your name

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a sub bulletin of an entry that has my name. But apparently that is not enough for the current script.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ahh, it is also not enough for me: I did not see it, too.

Thus you did not change any code, we can merge this even without the okay from the build server.

Please set "ready to merge" when you fixed everything from the review.

@@ -1,34 +1,56 @@
# Trying out Elektra with Docker
# Elektra Docker Artifacts
This folder contains all Docker related Artifacts.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

artifacts

```sh
$ mkdir data
$ docker run --rm -v ${PWD}/data:/mnt/share -it buildelektra bash
docker build -t buildelektra-stretch-full \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about adding a script for this command?

E.g. scripts/docker-build

```sh
$ buildelektra -b elektra master
docker run -it --rm \
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, what about a docker-run script?

```

When you exit the container you will find the created .deb package and the downloaded snapshots of Elektra in the data directory.
Note since we used matching userid + groupid to your current user the container
will write to your mounted directory with the correct permissions.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

will write to your mounted directory with the correct permissions.

Once you are running inside the container you can use the same commands as you
would use normally to configure, compile and test Elektra.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please refer to BUILDSERVER.md and/or Jenkinsfile here.

Afterwards it executes each step via `docker exec`.

There might be some more differences that might influence test outcomes.
One such documented case is #2008 and #1973 where errors on the test
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please link using https://issues.libelektra.org/2008 https://issues.libelektra.org/1973

I reproducibly (always) get the error with TMPDIR=`pwd`/x ctest -R rypt.

@petermax2 however seems to not get this error with the Docker images. @petermax2 can you retry with the commands posted here?

Copy link
Member

@petermax2 petermax2 Jun 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I build with

cmake -DBUILD_DOCUMENTATION=OFF -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ..
make -j16
mkdir x
TMPDIR=`pwd`/x ctest -R crypt.
Test project /elektra/build
	Start 46: testmod_crypto_openssl
1/3 Test #46: testmod_crypto_openssl ...........   Passed    1.32 sec
	Start 47: testmod_crypto_gcrypt
2/3 Test #47: testmod_crypto_gcrypt ............   Passed    1.16 sec
	Start 48: testmod_crypto_botan
3/3 Test #48: testmod_crypto_botan .............   Passed    1.52 sec

100% tests passed, 0 tests failed out of 3

Label Time Summary:
memleak    =   1.16 sec (1 test)

Total Test time (real) =   4.01 sec

EDIT: after following the instructions posted above inside the docker container. The error does not occur.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we have this discussion maybe at the affected PR and not here? Code comments in PR's get buried so easy.

$ buildelektra "0.8.19"
```
Please note that the complete images used to test Elektra are quite big
(~3.7GB) and take a some time (10min+) to build.
Copy link
Contributor

@markus2330 markus2330 Jun 4, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really 10min? On my fast machine with excellent Internet connection (TU network) it seemed to be longer.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Image creation is usually not capped by network speed but disk IO. On my local VM I can build the stretch image we use in 10 minutes. On the build servers it is a lot slower (especially on a7). It is even slower than expected honestly.

docker run -it --rm \
-v `pwd`:/home/jenkins/workspace \
-w /home/jenkins/workspace \
buildelektra-stretch-full
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Works excellent, but googletest-download was executed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not for me, can you recheck if you maybe have an old version checked out?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, I have been on the branch omnidan-elektra-web1.5

@markus2330 markus2330 merged commit f4174fe into ElektraInitiative:master Jun 5, 2018
@markus2330
Copy link
Contributor

Thank you, much better now!

An overview about which Dockerfiles we have now would be great. I added it to #1974

@ingwinlu
Copy link
Contributor Author

ingwinlu commented Jun 5, 2018 via email

@markus2330
Copy link
Contributor

Then a cross-reference to the Jenkinsfile + some info about what the Dockerfiles are about directly at the definition is the better solution.

@ingwinlu ingwinlu deleted the redo_docker_readme branch June 5, 2018 09:13
@ingwinlu
Copy link
Contributor Author

ingwinlu commented Jun 5, 2018

Then a cross-reference to the Jenkinsfile

That makes sense.

some info about what the Dockerfiles are about

Not sure what information you want here. Note you can easily grab the tests that run on an image by searching for (as an example) DOCKER_IMAGES.sid in the Jenkinsfile.

If you want to solve the issue of 'where do I need to install packages of my new dependency' then I do not have an answer. Because it will always depend on where you want to test it.

And it will always be the contributors responsibility to make sure all additions are actually tested. Similarly like you would have to modify cmake to include your new files in builds.

@ingwinlu
Copy link
Contributor Author

ingwinlu commented Jun 5, 2018

Similarly I would like to argue that it is the maintainers responsibility to check if the tests ran where every it is appropriate.

A task made significantly harder because of the 'silent removal policy' in some parts of the cmake setup.

@ingwinlu
Copy link
Contributor Author

ingwinlu commented Jun 5, 2018

I just had another look at it and it seems like I already referenced the Jenkinsfile as a source for commands executed in the containers.

markus2330 pushed a commit that referenced this pull request Jun 5, 2018
- add reference to Jenkinsfile
- use https links
- add empty lines after sections
- put note as quotes
omnidan pushed a commit to omnidan/libelektra that referenced this pull request Jun 18, 2018
- add reference to Jenkinsfile
- use https links
- add empty lines after sections
- put note as quotes
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants