Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker: Integration tests + Dianoga Docker Assets Images #109

Merged
merged 14 commits into from
Apr 25, 2022

Conversation

Antonytm
Copy link
Contributor

This PR includes:

  1. Automation to prepare Dianoga Docker Image Assets with different configurations. (different .Net versions)
    https://hub.docker.com/repository/docker/antonytm/dianoga-assets
    Currently, they are pushed to my Docker Hub account, but once this automation will be applied to the main one, I am happy to remove it. All that will be required: adding DOCKERHUB_TOKEN and DOCKERHUB_USERNAME as secrets to GitHub Actions.

(It is always a headache to install modules to containers because it will require preparing new images. And that is not only about Dianoga that is about all modules. That is why I think it will be nice to have assets images for Dianoga that could be easily added to containers in exact same way as for SPE, SXA, Horizon, etc.)

  1. Integration tests based on Docker Images
    After applying "NextGen" format changes, I wonder how many different configurations should be tested.(Sync, Async, enabled SVG, enabled WebP, enabled CDN, ...) That is why I did automation to cover some configurations that different Sitecore sites have now(and will have in the nearest future).
    a) Async default config
    b) Sync default config
    c) +SVG enabled
    d) +SVG +WEBP enabled
    e) +SVG +WEBP +AVIF +JXL enabled

Also, all these docker-compose configurations could be used for testing and development. It is much easier to run docker-compose up and start doing some feature or fix for Dianoga rather than preparing the environment first.

Please let me know if you are interested in having all this stuff (or part of this stuff). If yes, I will add more documentation about it.

P.S. There are things that should be improved and I planned to do. But due to the situation in Ukraine, I will not have time to do these things in the nearest future. But also having all these things and forgetting about them is not the right way as a lot of things were done.

P.S.2. You can merge these changes not to the main branch and firstly try them.

pick 1df3216 Integration tests: get rid from not needed containers/images
pick 289a7c2 Integration tests: removed not needed images
pick 8ae2866 Integration-tests: deploy content
pick 033a530 Integration tests: make sure that they will pass even on slow computers
pick 71b71e1 Adding comments
pick f8fea9a Adding comments
pick a7b265b Docker image CI
squash bf3881b Change Github Action branch
squash 18ce0cc Disable Buildx
squash 1460fb6 Try other GitHub action
squash 118d998 Dockerfile.CI > Dockerfile
squash 7691ef7 Change registry and image settings
squash 9983128 Pass build number to tags
squash f7b18d5 Pass additional environment variables
squash cbbdb83 Attempt to pass args in different way
squash bd1df76 Figuring out the proper way to pass --build-arg
squash 13a40e1 Attempt to use build args in different format
squash d5b2dbc Attempt to use build args in different format
squash f4dfeb0 Debug info for GitHub Actions build
squash 627b01c Use Docker COPY command instead of Powershell Copy
squash 6f9456e Try to use variables
squash 2b8ca94 Hardcode files path to test CI
squash 6b8c1f4 One more try with hardcoded paths
squash fdc5386 One more attempt with variables
squash bd73e73 Debug Docker build
squash e56e3a5 Try absolute path for COPY
squash a9c3646 Attempt to use hardcoded paths
squash b6fc72b Copy path that definitely exists
squash 4af1834 Try to use from parameter
squash 05e54a8 Use command line + hardcode
squash 6565698 Attempt to pass value thought separate file
squash 3997054 Add debug info
squash b4ef081 Mkdir bin before copy
squash fffca4d Change image name
squash 3121152 Change registry URL
squash 346e97a Update Docker Hub secrets
squash b0abecf Tag image by build number
squash 1e6a540 Simplify build
squash 73ca41d Attempt to use composites for GitHub Actions
squash 2a24c09 Fix file extension
squash dd20f1e Move file according to Github conventions
squash 83a0256 Specify action branch
squash d5c0320 Use Git ref to specify action
squash 89bd70c Checkout code before running action
squash 1b94e00 Pass Docker Registry credential as inputs
squash 2d09b18 Separate workflow per configuration
squash 4954a3c Remove draft Docker CI workflow
@markgibbons25
Copy link
Collaborator

I don't actually use docker myself, but this does look great.

@markgibbons25 markgibbons25 merged commit 4da52bf into kamsar:master Apr 25, 2022
@monkey-ldb
Copy link

hi @markgibbons25 , @Antonytm
is there now somewhere an official image on a public registry for the dianoga assets?
I was only able to find this: https://hub.docker.com/r/antonytm/dianoga-assets/tags
is this for production or only test usage?

@Antonytm
Copy link
Contributor Author

@monkey-ldb

It is not an official one:
https://hub.docker.com/r/antonytm/dianoga-assets/tags

It is actually built from my fork: https://github.com/antonytm/dianoga, using GitHub actions:
E.g. https://github.com/Antonytm/Dianoga/actions/workflows/Dianoga-Docker-NET48-Release.yml

However, I know at least 2 projects, where that image was used in production. And I am not involved in any of these projects.

The building of this image is completely transparent: everything happens on Github actions. You may review them.

If you have any doubts, you always are able to build your own image:

  1. Form the repo
  2. Create Docker Hub account
  3. Set DOCKERHUB_TOKEN and DOCKERHUB_USERNAME secrets
  4. Run actions

I described whole process in detail here:
https://exdst.com/posts/20220728-sitecore-docker-github-actions

@Antonytm
Copy link
Contributor Author

Moving forward:
I don't want to "steal" Dianoga and host official Docker images under my account "antonytm" on Docker Hub.
It will be fairer to either host it under "kamsar" account or create a new Dianoga-specific Docker Hub account.

In order to build an "official" image, we need:

  1. Create a Docker Hub account (free of charge for open source).
  2. Add DOCKERHUB_TOKEN and DOCKERHUB_USERNAME secrets to kamsar/dianoga repository. (I don't have access to do it. The settings tab is unavailable for me.)
  3. Run Github actions that build images

I will rely on @markgibbons25 opinion on these questions:

  1. Do we need an official Dianoga Docker Image asset image?
  2. What account should we use for hosting this image?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants