mirror of
https://github.com/jupyter/docker-stacks.git
synced 2025-10-15 14:02:58 +00:00
Fix more minor typos
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
# Jupyter Docker Stacks
|
||||
|
||||
[](https://github.com/jupyter/docker-stacks/actions/workflows/docker.yml?query=branch%3Amain "Docker images build status")
|
||||
[](https://github.com/jupyter/docker-stacks/actions/workflows/docker.yml?query=branch%3Amain "Docker images build status")
|
||||
[](https://jupyter-docker-stacks.readthedocs.io/en/latest/ "Documentation build status")
|
||||
[](https://results.pre-commit.ci/latest/github/jupyter/docker-stacks/main "pre-commit.ci build status")
|
||||
[](https://discourse.jupyter.org/ "Jupyter Discourse Forum")
|
||||
|
@@ -71,7 +71,7 @@ git push -u origin main
|
||||
|
||||
1. By default, the newly `.github/workflows/docker.yaml` will trigger the CI pipeline whenever you push to your `main` branch
|
||||
and when any Pull Requests are made to your repository.
|
||||
For more details on this configuration, visit the [GitHub actions documentation on triggers](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows).
|
||||
For more details on this configuration, visit the [GitHub Actions documentation on triggers](https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows).
|
||||
|
||||
2. Go to your repository and click on the **Actions** tab.
|
||||
From there, you can click on the workflows on the left-hand side of the screen.
|
||||
|
@@ -46,7 +46,7 @@ The prefix of commit hash (namely, 12 letters) is used as an image tag to make i
|
||||
|
||||
### Tagger
|
||||
|
||||
`Tagger` is a class that can be run inside a docker container to calculate some tag for an image.
|
||||
`Tagger` is a class that can be run inside a docker container to calculate a tag for an image.
|
||||
|
||||
All the taggers are inherited from `TaggerInterface`:
|
||||
|
||||
@@ -91,6 +91,6 @@ and `markdown_piece(container)` method returns a piece of the build manifest.
|
||||
|
||||
## Images Hierarchy
|
||||
|
||||
All images' dependencies on each other and what taggers and manifest are applicable to them are defined in `hierarchy/images_hierarchy.py`.
|
||||
All images' dependencies on each other and what taggers and manifests are applicable to them are defined in `hierarchy/images_hierarchy.py`.
|
||||
|
||||
`hierarchy/get_taggers_and_manifests.py` defines a function to get the taggers and manifests for a specific image.
|
||||
|
@@ -10,8 +10,8 @@ To build new images and publish them to the Registry, do the following:
|
||||
|
||||
```{note}
|
||||
GitHub Actions are pretty reliable, so please investigate if some error occurs.
|
||||
Building Docker images in PRs is the same as building them in the default branch,
|
||||
except single-platform images are pushed to Registry and then tags are merged for `x86_64` and `aarch64`.
|
||||
Building Docker images in PRs is the same as building them in the default branch.
|
||||
The only difference is that single-platform images are pushed to Registry and then tags are merged for `x86_64` and `aarch64`.
|
||||
```
|
||||
|
||||
4. Avoid merging another PR to the main branch until all pending builds in the main branch are complete.
|
||||
@@ -29,12 +29,12 @@ When a new `Python` version is released, we wait for:
|
||||
## Updating the Ubuntu Base Image
|
||||
|
||||
`jupyter/docker-stacks-foundation` is based on the LTS Ubuntu docker image.
|
||||
We are waiting for the first point release of the new LTS Ubuntu before updating the version.
|
||||
Other images are directly or indirectly inherited from `docker-stacks-foundation`.
|
||||
We wait for the first point release of the new LTS Ubuntu before updating the version.
|
||||
Other images are directly or indirectly inherited from `jupyter/docker-stacks-foundation`.
|
||||
We rebuild our images automatically each week, which means they frequently receive updates.
|
||||
|
||||
When there's a security fix in the Ubuntu base image, it's a good idea to manually trigger the rebuild of images
|
||||
[from the GitHub actions workflow UI](https://github.com/jupyter/docker-stacks/actions/workflows/docker.yml).
|
||||
[from the GitHub Actions workflow UI](https://github.com/jupyter/docker-stacks/actions/workflows/docker.yml).
|
||||
Pushing the `Run Workflow` button will trigger this process.
|
||||
|
||||
## Adding a New Core Image to the Registry
|
||||
@@ -67,5 +67,5 @@ When there's a new stack definition, check before merging the PR:
|
||||
|
||||
## Restarting a failed build
|
||||
|
||||
If an automated build in GitHub Actions has got you down, you can restart failed steps on GitHub.
|
||||
If an automated build in GitHub Actions fails, you can restart the failed jobs on GitHub.
|
||||
You can also download the artifacts and investigate them for any issues.
|
||||
|
Reference in New Issue
Block a user