|
1 | | -## Docker images |
2 | | - |
3 | | -The docker images for `dnmtools` are hosted in GitHub Container registry. The |
4 | | -process of building and pushing the image to the registry is handled by the |
5 | | -workflow specified in |
6 | | -[docker-build.yml](https://github.com/smithlabcode/dnmtools/blob/master/.github/workflows/docker-build.yml). |
7 | | -The build instruction is in |
8 | | -[Dockerfile](https://github.com/smithlabcode/dnmtools/blob/master/Dockerfile). |
9 | | -You can see the published images |
10 | | -[here](https://github.com/smithlabcode/dnmtools/pkgs/container/dnmtools). |
11 | | - |
12 | | -The workflow is triggered either manually or automatically by a tag event of |
13 | | -type `v*.*.*`, which is intended for new releases. Currently, publishing the |
14 | | -images can happen only to commits tagged by a version number. This is intended |
15 | | -to associate every docker image with a version number. This means that there is |
16 | | -no option to push the image for the latest commit if it is not tagged by |
17 | | -a version number. |
18 | | - |
19 | | -### Automatic build and publish in a tag event |
20 | | - |
21 | | -In a tag event of type `v*.*.*`, such as new release or retagging of versoin |
22 | | -number, this work flow is triggered to build and publish the image for the |
23 | | -tagged version number. The published image is tagged with SHA hash and the |
24 | | -version number. It is also taged with `latest` if the version number is the |
25 | | -latest. |
26 | | - |
27 | | -### Manual build (and publish) |
28 | | - |
29 | | -Manual trigger is intedned to test the image build processes as well as publish |
30 | | -an image for an existing version. In |
31 | | -[Actions](https://github.com/smithlabcode/dnmtools/actions), go to `Docker image |
32 | | -build` under `All workflows` and click `Run workflow` and choose from the |
33 | | -following options: |
34 | | - |
35 | | -1. `Build latest commit`: for testing for the latest commit |
36 | | -2. `Build existing version`: for testing a particular version |
37 | | -3. `Build + push existing version`: for publishing a particular version |
38 | | - |
39 | | -For options 2 and 3, specify the version number in the form `v*.*.*`. If not |
40 | | -specified, the workflow will assume the latest verion. |
41 | | - |
42 | | -### Use scenarios |
43 | | - |
44 | | -**Before a new release**: It is a good idea to test image building before a new |
45 | | -release. Manually trigger the workflow with opiton 1. If it builds with no |
46 | | -issues, make a new release and the image will automatically be built and |
47 | | -published. |
48 | | - |
49 | | -**Publish an existing version**: It is possible to publish a docker image for an |
50 | | -existing version by option 3 in the manual trigger. First, test build using |
51 | | -option 2, and then publish using option 3. The published image is tagged with |
52 | | -SHA hash and the version number. It is also taged with `latest` if the version |
53 | | -number is the latest. If option 3 is deployed with a version number for which |
54 | | -a docker image already exists, it will simply rebuild and update the existing |
55 | | -image. |
56 | | - |
57 | | -**Deleting an image**: If you have owner access to `smithlabcode`, you can |
58 | | -delete an image by going |
59 | | -[here](https://github.com/smithlabcode/dnmtools/pkgs/container/dnmtools/versions) |
60 | | -and manually delete a version. |
61 | | - |
62 | | - |
63 | | - |
64 | | -## Installation |
65 | | -The image can be pulled by one of the following commands. |
66 | | - |
67 | | -```bash |
68 | | -docker pull ghcr.io/smithlabcode/dnmtools:latest |
69 | | -docker pull ghcr.io/smithlabcode/dnmtools:[7-DIGIT SHA] |
70 | | -docker pull ghcr.io/smithlabcode/dnmtools:v[VERSION NUMBER] #(e.g. v1.3.0) |
71 | | -``` |
72 | | - |
| 1 | +## Docker images |
| 2 | + |
| 3 | +The docker images for `dnmtools` are hosted in GitHub Container registry. The |
| 4 | +process of building and pushing the image to the registry is handled by the |
| 5 | +workflow specified in |
| 6 | +[docker-build.yml](https://github.com/smithlabcode/dnmtools/blob/master/.github/workflows/docker-build.yml). |
| 7 | +The build instruction is in |
| 8 | +[Dockerfile](https://github.com/smithlabcode/dnmtools/blob/master/Dockerfile). |
| 9 | +You can see the published images |
| 10 | +[here](https://github.com/smithlabcode/dnmtools/pkgs/container/dnmtools). |
| 11 | + |
| 12 | +The workflow is triggered either manually or automatically by a tag event of |
| 13 | +type `v*.*.*`, which is intended for new releases. Currently, publishing the |
| 14 | +images can happen only to commits tagged by a version number. This is intended |
| 15 | +to associate every docker image with a version number. This means that there is |
| 16 | +no option to push the image for the latest commit if it is not tagged by |
| 17 | +a version number. |
| 18 | + |
| 19 | +### Automatic build and publish in a tag event |
| 20 | + |
| 21 | +In a tag event of type `v*.*.*`, such as new release or retagging of versoin |
| 22 | +number, this work flow is triggered to build and publish the image for the |
| 23 | +tagged version number. The published image is tagged with SHA hash and the |
| 24 | +version number. It is also taged with `latest` if the version number is the |
| 25 | +latest. |
| 26 | + |
| 27 | +### Manual build (and publish) |
| 28 | + |
| 29 | +Manual trigger is intedned to test the image build processes as well as publish |
| 30 | +an image for an existing version. In |
| 31 | +[Actions](https://github.com/smithlabcode/dnmtools/actions), go to `Docker image |
| 32 | +build` under `All workflows` and click `Run workflow` and choose from the |
| 33 | +following options: |
| 34 | + |
| 35 | +1. `Build latest commit`: for testing for the latest commit |
| 36 | +2. `Build existing version`: for testing a particular version |
| 37 | +3. `Build + push existing version`: for publishing a particular version |
| 38 | + |
| 39 | +For options 2 and 3, specify the version number in the form `v*.*.*`. If not |
| 40 | +specified, the workflow will assume the latest verion. |
| 41 | + |
| 42 | +### Use scenarios |
| 43 | + |
| 44 | +**Before a new release**: It is a good idea to test image building before a new |
| 45 | +release. Manually trigger the workflow with opiton 1. If it builds with no |
| 46 | +issues, make a new release and the image will automatically be built and |
| 47 | +published. |
| 48 | + |
| 49 | +**Publish an existing version**: It is possible to publish a docker image for an |
| 50 | +existing version by option 3 in the manual trigger. First, test build using |
| 51 | +option 2, and then publish using option 3. The published image is tagged with |
| 52 | +SHA hash and the version number. It is also taged with `latest` if the version |
| 53 | +number is the latest. If option 3 is deployed with a version number for which |
| 54 | +a docker image already exists, it will simply rebuild and update the existing |
| 55 | +image. |
| 56 | + |
| 57 | +**Deleting an image**: If you have owner access to `smithlabcode`, you can |
| 58 | +delete an image by going |
| 59 | +[here](https://github.com/smithlabcode/dnmtools/pkgs/container/dnmtools/versions) |
| 60 | +and manually delete a version. |
| 61 | + |
| 62 | + |
| 63 | + |
| 64 | +## Installation |
| 65 | +The image can be pulled by one of the following commands. |
| 66 | + |
| 67 | +```bash |
| 68 | +docker pull ghcr.io/smithlabcode/dnmtools:latest |
| 69 | +docker pull ghcr.io/smithlabcode/dnmtools:[7-DIGIT SHA] |
| 70 | +docker pull ghcr.io/smithlabcode/dnmtools:v[VERSION NUMBER] #(e.g. v1.4.0) |
| 71 | +``` |
| 72 | + |
0 commit comments