What

When Dockerfile or requirements.txt (Pipfile, etc.) modifies - need to rebuild, test new image and replace previous one with keeping history. How can this be done?

ToDo

1. Trigger docker build job on changes
   1. Dockerfile;
   2. CI file with "docker build job";
   3. Requirements.txt / Pipfile / etc. whatever with dependencies
2. Run tests on new docker image.
3. If tests passed - replace docker image in registry or ci files, but keep the previous version of image.

What?

Clean allure attachments of passed tests after building allure-report.

Why?

In case to save disk space by removing most useless kind of reports information. Tests are passing always - it is their normal behavior. And passing tests generates tons of attachments with very low percent of usage. Nobody watch them often. The have a very rare use cases: Try to find anyone? -Can't find one? -That's what I am talking about!

Plan

GitLab CI/CD & Docker

1. How GitLab works. What for are yml instructions, how it listens this, links links links 1,2,3,4 to the official docs about gitlab runners and executors. Describe why docker executor is the best for the most of common cases.
2. Create simple script with installing dependencies in it to show the work of CI/CD. Describe why it's a bad practice. And move to the next step with best practice with Docker.
3. Create simple Dockerfile with dependencies. Describe what base distributives exist and what's the difference between them or find a link to the article explains this.
4. Make and push Docker image to GitLab Container Registry.
5. Show how to use your own image from registry in CI/CD scripts.

Tests and GitLab CI/CD

1. Simple job with image from registry.
2. Schedule tests nightly.
3. Tests on push is a time waste. Good at start. Bad in the distance. Describe how to still run them but not on every push.
4. Trigger tests from another project pipeline.
5. Show the CI/CD variables and manual runs. As example - custom test suite or special environment.
6. Schedule tests for different test environments.
7. Differentiate test:test stages & jobs for each test environment in schedules to easy find them in Pipelines and Jobs list.
8. Schedule more test suites. Mono-repository example.
9. Parallel job execution on the same runners - link to official docs.
10. Big daddy pipelines. Group test suites which can be executed in parallel on the same environment and make the pipeline from all of these groups.

Story

It seems that many opensource contributors from GitHub wants to see count of total downloads of their projects. But now it is only available 14 days history.
But you can help these people to start summarize the download statistics right now. To achieve that you need to resolve this issue and make a PR.

ToDo

1. Make a job that will be executed once a week, downloading its previous artifacts and saving new artifacts.
2. Write a script that will be executed by the weekly job. The script should call GitHub API project statistic and took count of downloads from it, saving them to the file. The script also should download artifact with count of downloads from previous job., summarize them with current count and write to new artifact which should be saved by the job.
3. Make a project badge which will be updated every time after the job.

Good luck, have fun!