diff --git a/docs/blog/posts/building-OKD-payload.md b/docs/blog/posts/building-OKD-payload.md index 3747a01f..6bfa31a4 100644 --- a/docs/blog/posts/building-OKD-payload.md +++ b/docs/blog/posts/building-OKD-payload.md @@ -27,26 +27,29 @@ In this article, I will shed some light on the building blocks of the OKD on SCO Until now, the OKD payload, like the OpenShift payload, was built by the [ReleaseController](https://github.com/openshift/release/tree/master/core-services/release-controller) in Prow. -> The release-controller automatically builds OpenShift release images when new images are created for a given OpenShift release. It detects changes to an image stream, launches a job to build and push the release payload image using `oc adm release new`, and then runs zero or more ProwJobs against the artifacts generated by the payload. +> The release-controller automatically builds OpenShift release images when new images are created for a given OpenShift release. It detects changes to an image stream, launches a job to build and push the release payload image using `oc adm release new`, and then runs zero or more ProwJobs against the artifacts generated by the payload. A release image is nothing more than a ClusterVersionOperator image (CVO), with an extra layer containing the `release-manifests` folder. This folder contains : -* `image-references`: a list of all known images with their SHA digest, -* yaml manifest files for each operator controlled by the CVO. + +- `image-references`: a list of all known images with their SHA digest, +- yaml manifest files for each operator controlled by the CVO. The list of images that is included in the `release-manifests` is calculated from the `release` [image stream](https://developers.redhat.com/blog/2019/09/20/using-red-hat-openshift-image-streams-with-kubernetes-deployments#), taking : -* all images with label `io.openshift.release.operator=true` in that image stream -* plus any images referenced in the `/manifests/image-references` file within each of the images with this label. + +- all images with label `io.openshift.release.operator=true` in that image stream +- plus any images referenced in the `/manifests/image-references` file within each of the images with this label. As you can imagine, the list of images in a release can change from one release to the next, depending on: -* new operators being delivered within the OpenShift release -* existing operators adding or removing an operand image -* operators previously included that are removed from the payload to be delivered independently, through OLM instead. + +- new operators being delivered within the OpenShift release +- existing operators adding or removing an operand image +- operators previously included that are removed from the payload to be delivered independently, through OLM instead. In order to list the images contained in a release payload, run this command: ```shell oc adm release info ${RELEASE_IMAGE_URL} -``` +``` For example: @@ -56,7 +59,7 @@ oc adm release info quay.io/okd/scos-release:4.12.0-0.okd-scos-2022-12-02-083740 Now that we've established what needs to be built, let's take a deeper look at how the OKD on SCOS payload is built. -## Building OKD/SCOS the Prow way `:railway_track:` +## Building OKD/SCOS the Prow way The obvious way to build OKD on SCOS is to use [Prow](https://docs.prow.k8s.io/docs/) - THE Kubernetes-based CI/CD system, which is what builds OCP and OKD on FCOS already today. This is what Kubernetes uses upstream as well. :shrug: @@ -71,28 +74,26 @@ For OKD on Fedora CoreOS (OKD/FCOS) it's named `okd`.For OKD/SCOS, this ImageStr This ImageStream includes all payload images contained in the specific `OKD` release based on CentOS Stream CoreOS (SCOS) Among these payload images, we distinguish: -* Images that can be shared between OCP and OKD. These are built in Prow and mirrored into the `okd-scos` ImageStream. -* Images that have to be specifically built for OKD/SCOS, which are directly tagged into the `okd-scos` ImageStream. This is the case for images that are specific to the underlying operating system, or contain RHEL packages. These are: the `installer` images, the `machine-config-operator` image, the `machine-os-content` that includes the base operating system OSTree, as well as the `ironic` image for provisioning bare-metal nodes, and a few other images. +- Images that can be shared between OCP and OKD. These are built in Prow and mirrored into the `okd-scos` ImageStream. +- Images that have to be specifically built for OKD/SCOS, which are directly tagged into the `okd-scos` ImageStream. This is the case for images that are specific to the underlying operating system, or contain RHEL packages. These are: the `installer` images, the `machine-config-operator` image, the `machine-os-content` that includes the base operating system OSTree, as well as the `ironic` image for provisioning bare-metal nodes, and a few other images. ### Triggers for building most payload images + Now that we've got the recipient Image Stream for the OKD payload images, let's start building some payloads! Take the [Cluster Network Operator](https://github.com/openshift/cluster-network-operator) for example: For this operator, the same image can be used on OCP CI and OKD releases. Most payload images fit into this case. For such an image, the build is pretty straight forward. When a PR is filed for a GitHub repository that is part of a release payload: -* The Pre-submit jobs run. It essentially builds the image and stores it in an ImageStream in an ephemeral namespace to run tests against several platforms (AWS, GCP, BareMetal, Azure, etc) -* Once the tests are green and the PR is approved and merges, the Post-submit jobs run. It essentially promotes the built image to the appropriate release-specific ImageStream: - * if the PR is for master, images are pushed to the `${next-release}` ImageStream - * If the PR is for `release-${MAJOR}.${MINOR}`, images are pushed to the `${MAJOR}.${MINOR}` ImageStream -Next, the [OCP release controller](https://github.com/openshift/release/blob/master/core-services/release-controller/_releases/release-ocp-4.13-ci.json#L12) which runs at every change to the ImageStream, will mirror all images from the `${MAJOR}.${MINOR}` ImageStream to the `scos-${MAJOR}.${MINOR}` ImageStream. +- The Pre-submit jobs run. It essentially builds the image and stores it in an ImageStream in an ephemeral namespace to run tests against several platforms (AWS, GCP, BareMetal, Azure, etc) +- Once the tests are green and the PR is approved and merges, the Post-submit jobs run. It essentially promotes the built image to the appropriate release-specific ImageStream: + - if the PR is for master, images are pushed to the `${next-release}` ImageStream + - If the PR is for `release-${MAJOR}.${MINOR}`, images are pushed to the `${MAJOR}.${MINOR}` ImageStream -isokd[(OKD IS scos-4.x)]; RCtrl -. from .- isci -``` ---> - -![release process](img/build_okd_payload_1.png) +``` As mentioned before, some of the images are not mirrored, and that brings us to the next section, on building those images that have content (whether code or manifests) specific to OKD. - ### Trigger for building the OKD-specific payload images -For the OKD-specific images, the CI process is a bit different, as the image is built in the PostSubmit job and then directly promoted to the `okd-scos` IS, without going through the OCP CI to OKD mirroring step. +For the OKD-specific images, the CI process is a bit different, as the image is built in the PostSubmit job and then directly promoted to the `okd-scos` IS, without going through the OCP CI to OKD mirroring step. This is called [a variant configuration](https://docs.ci.openshift.org/docs/how-tos/contributing-openshift-release/#variants). You can see this for [MachineConfigOperator](https://github.com/openshift/release/blob/master/ci-operator/config/openshift/machine-config-operator/openshift-machine-config-operator-master__okd-scos.yaml) for example. -PreSubRHCOS{{fa:fa-gears fa:fa-prow PreSubmitJob / OCP CI}}; + PR[PullRequest]-- submitted -->PreSubRHCOS{{PreSubmitJob / OCP CI}}; PreSubRHCOS:::RHCOS-- builds -->tis[(temporary IS)]; PreSubRHCOS-- runs -->testRHCOS{{Platform tests}}; testRHCOS:::RHCOS -. against .- tis - PR[fa:fa-github PullRequest]-- submitted -->PreSubSCOS{{fa:fa-gears fa:fa-prow PreSubmitJob / OKD}}; + PR[PullRequest]-- submitted -->PreSubSCOS{{PreSubmitJob / OKD}}; PreSubSCOS:::SCOS-- builds -->tis[(temporary IS)]; PreSubSCOS-- runs -->testSCOS{{Platform tests}}; testSCOS:::SCOS -. against .- tis - PR-- merged -->PostSubRHCOS{{fa:fa-gears PostSubmitJob / OCP CI}}; + PR-- merged -->PostSubRHCOS{{PostSubmitJob / OCP CI}}; PostSubRHCOS:::RHCOS-- promotes -->isocp[(OCP CI IS 4.x)]; PostSubRHCOS -. from .- tis - PR-- merged -->PostSubSCOS{{fa:fa-gears PostSubmitJob / OKD}}; + PR-- merged -->PostSubSCOS{{PostSubmitJob / OKD}}; PostSubSCOS:::SCOS-- promotes -->isokd[(OKD IS scos-4.x)]:::SCOS; PostSubSCOS -. from .- tis classDef RHCOS fill:; - classDef SCOS fill:#1e97fa; + classDef SCOS fill:#1e77aa; ``` ---> - -![trigger for building](img/build_okd_payload_2.png) -The built images land directly in the `scos-${MAJOR}-${MINOR}` ImageStream. +The built images land directly in the `scos-${MAJOR}-${MINOR}` ImageStream. -That is why there's no need for OCP's CI release controller to mirror these images from the CI ImageStream: +That is why there's no need for OCP's CI release controller to mirror these images from the CI ImageStream: During the PostSubmit phase, images are already getting built in parallel for OCP, OKD/FCOS and OKD/SCOS and pushed, respectively to `ocp/$MAJOR.$MINOR`, `origin/$MAJOR.$MINOR`, `origin/scos-$MAJOR.$MINOR` - - ### OKD release builds Now the ImageStream `scos-$MAJOR.$MINOR` is getting populated by payload images. With every new image tag, the [release controller for OKD/SCOS](https://github.com/openshift/release/blob/master/core-services/release-controller/_releases/release-okd-scos-4.13.json) will build a release image. @@ -161,14 +152,14 @@ Now the ImageStream `scos-$MAJOR.$MINOR` is getting populated by payload images. The ReleaseController ensures that OpenShift update payload images (aka release images) are created whenever an ImageStream representing the images in a release is updated. Thanks to the annotation `release.openshift.io/config` on the `scos-${MAJOR}-{MINOR}` ImageStream, the controller will: + 1. Create a tag in the `scos-${MAJOR}-{MINOR}` ImageStream that uses the release name + current timestamp. 2. Mirror all of the tags in the input ImageStream so that they can't be pruned. 3. Launch a job in the job namespace to invoke `oc adm release new` from the mirror pointing to the release tag we created in step 1. -4. If the job succeeds in pushing the tag, it sets an annotation on that tag `release.openshift.io/phase = "Ready"`, indicating that the release can be used by other steps. And that's how a new release appears in https://origin-release.ci.openshift.org/#4.13.0-0.okd-scos +4. If the job succeeds in pushing the tag, it sets an annotation on that tag `release.openshift.io/phase = "Ready"`, indicating that the release can be used by other steps. And that's how a new release appears in [`https://origin-release.ci.openshift.org/#4.13.0-0.okd-scos](https://origin-release.ci.openshift.org/#4.13.0-0.okd-scos) 5. The release state switches to "Verified" when the [verification end-to-end test job](https://github.com/openshift/release/blob/master/core-services/release-controller/_releases/release-okd-scos-4.13.json#L20) succeeds. - -## Building the Tekton way :motorway: +## Building the Tekton way Building with Prow has the advantage of being driven by new code being pushed to payload components, thus building fresh releases as the code of [github.com/openshift](https://github.com/openshift) evolves. @@ -179,18 +170,18 @@ To remove this impediment, the OKD team has been working on the OKD Payload pipe Building OKD payloads with Tekton can be done by cloning the [okd-payload-pipeline repository](https://github.com/okd-project/okd-payload-pipeline). One extra advantage of this repository is the ability to see the list of components that form the OKD payload: In fact, the list under [buildconfigs](https://github.com/okd-project/okd-payload-pipeline/tree/main/buildconfigs) corresponds to the images in the OKD final payload. This list is currently manually synced with the list of OCP images on each release. The pipeline is fairly simple. Take the [build-from-scratch.yaml](https://github.com/okd-project/okd-payload-pipeline/blob/main/pipelines/build-from-scratch.yaml) for example. It has 3 main tasks: -* Build the base image and the builder image, with which all the payload images will be built - * The builder image is a CentOS Stream 9 container image that includes all the dependencies needed to build payload components and is used as the build environment for them - * The built binaries are then layered onto a CentOS Stream 9 base image, creating a payload component image. - * The base image is shared across all the images in the release payload -* Build payload images in batches (starting with the ones that don't have any dependencies) -* Finally, as all OKD payload component images are in the image stream, the OKD release image is in turn built, using the `oc adm release new` command. - - taskRunBuilderBase{{fa:fa-gears TaskRun - BatchBuild}} @@ -221,9 +212,6 @@ graph TB end ``` ---> - -![pipeline](img/build_okd_payload_3.png) ### Triggers @@ -239,7 +227,7 @@ This task simply uses an OpenShift client image to call `oc adm release new` whi ### BuildConfigs -As explained above, the OKD payload Tekton pipeline heavily relies on the [buildconfigs](https://github.com/okd-project/okd-payload-pipeline/tree/main/buildconfigs). +As explained above, the OKD payload Tekton pipeline heavily relies on the [buildconfigs](https://github.com/okd-project/okd-payload-pipeline/tree/main/buildconfigs). This folder contains one buildconfig yaml file for each image included in the release payload. Each build config simply uses a builder image to build the operator binary, invoking the correct Dockerfile in the operator repository. Then, the binary is copied as a layer on top of an OKD base image, which is built in the preparatory task of the pipeline. @@ -249,9 +237,10 @@ This process currently uses the [OpenShift Builds API](https://docs.okd.io/4.11/ ### Updating build configs Upon deploying the Tekton OKD Payload pipeline on an OKD (or OpenShift) cluster, Kustomize is used in order to : -* patch the BuildConfig files, adding TAGS to the build arguments according to the type of payload we want to build (based on FCOS, SCOS or any other custom stream) -* patch the BuildConfig files, replacing the builder image references to the non-public `registry.ci.openshift.org/ocp/builder` in the payload component's Dockerfiles with the builder image reference from the local image stream -* setting resource requests and limits if needed + +- patch the BuildConfig files, adding TAGS to the build arguments according to the type of payload we want to build (based on FCOS, SCOS or any other custom stream) +- patch the BuildConfig files, replacing the builder image references to the non-public `registry.ci.openshift.org/ocp/builder` in the payload component's Dockerfiles with the builder image reference from the local image stream +- setting resource requests and limits if needed ### Preparing for a new release @@ -261,33 +250,35 @@ To build a new release, each BuildConfig file should be updated with the git bra In the future, the branch can be passed along as a kustomization, or in the parameters of the pipeline. The list of images from a new OCP release (obtained through `oc adm release info`) must now be synced with the BuildConfigs present here: -* For any new image, a new BuildConfig file must be added -* For any image removed from the OCP release, the corresponding BuildConfig file must be removed. +- For any new image, a new BuildConfig file must be added +- For any image removed from the OCP release, the corresponding BuildConfig file must be removed. ## Take away ### What are our next steps? + In the coming weeks and months, you can expect lots of changes, especially as the OKD community is picking up usage of OKD/SCOS, and doing their own Tekton Pipeline runs: -* Work to automate the OKD release procedure is progress by automatically verifying payload image signatures, signing the release, and tagging it on GitHub. - The goal is to deliver a new OKD/SCOS on a sprint (3-weekly) basis, and to provide both the OCP teams and the OKD community with a fresh release to test much earlier than previously with the OCP release cadence. -* For the moment, OKD/SCOS releases are only verified on AWS. To gain more confidence in our release payloads, we will expand the test matrix to other platforms such as GCP, vSphere and Baremetal -* Enable GitOps on the Tekton pipeline repository, so that changes to the pipeline are automatically deployed on [OperateFirst](https://www.operate-first.cloud/) for the community to use the latest and greatest. -* The OKD Working Group will be collaborating with the [Mass Open Cloud](https://massopen.cloud/) to allow for deployments of test clusters on their baremetal infrastructure. -* The OKD Working Group will be publishing the Tekton Tasks and Pipelines used to build the SCOS Operating System as well as the OKD payload to [Tekton Hub](https://hub.tekton.dev/) and [Artifact Hub](https://artifacthub.io/) -* The [OKD operators Tekton pipeline](https://github.com/okd-project/okd-operator-pipeline/) will be used for community builds of optional OLM operators. A first OKD operator has already been built with it, and other operators are to follow, starting with the Pipelines operator, which has long been an ask by the community -* Additionally, we are working on multi-arch releases for both OKD/SCOS and OKD/FCOS +- Work to automate the OKD release procedure is progress by automatically verifying payload image signatures, signing the release, and tagging it on GitHub. + +The goal is to deliver a new OKD/SCOS on a sprint (3-weekly) basis, and to provide both the OCP teams and the OKD community with a fresh release to test much earlier than previously with the OCP release cadence. +- For the moment, OKD/SCOS releases are only verified on AWS. To gain more confidence in our release payloads, we will expand the test matrix to other platforms such as GCP, vSphere and Baremetal +- Enable GitOps on the Tekton pipeline repository, so that changes to the pipeline are automatically deployed on [OperateFirst](https://www.operate-first.cloud/) for the community to use the latest and greatest. +- The OKD Working Group will be collaborating with the [Mass Open Cloud](https://massopen.cloud/) to allow for deployments of test clusters on their baremetal infrastructure. +- The OKD Working Group will be publishing the Tekton Tasks and Pipelines used to build the SCOS Operating System as well as the OKD payload to [Tekton Hub](https://hub.tekton.dev/) and [Artifact Hub](https://artifacthub.io/) +- The [OKD operators Tekton pipeline](https://github.com/okd-project/okd-operator-pipeline/) will be used for community builds of optional OLM operators. A first OKD operator has already been built with it, and other operators are to follow, starting with the Pipelines operator, which has long been an ask by the community +- Additionally, we are working on multi-arch releases for both OKD/SCOS and OKD/FCOS ### Opened perspectives Although in the near future the OKD team will still rely on Prow to build the payload images, the Tekton pipeline will start getting used to finalize the release. -In addition, this Tekton pipeline has opened up new perspectives, even for OCP teams. +In addition, this Tekton pipeline has opened up new perspectives, even for OCP teams. One such example is for the [Openshift API team](https://github.com/openshift/api) who would like to use the Tekton pipeline to test API changes by building all components that are dependent of the OpenShift API from that PR, create an OKD release and test it thus getting extra quick feedback on impacts of the API changes on the OKD (and later OCP) releases. Another example is the possibility to build images on other platforms than Openshift or OKD platform, replacing build configs with Shipwright, or why not `docker build`... -Whatever your favorite flavor is, we are looking forward to seeing the pipelines in action, increasing collaboration and improving our community feedback loop. \ No newline at end of file +Whatever your favorite flavor is, we are looking forward to seeing the pipelines in action, increasing collaboration and improving our community feedback loop. diff --git a/docs/blog/posts/img/build_okd_payload_1.png b/docs/blog/posts/img/build_okd_payload_1.png deleted file mode 100644 index e3a0aa7e..00000000 Binary files a/docs/blog/posts/img/build_okd_payload_1.png and /dev/null differ diff --git a/docs/blog/posts/img/build_okd_payload_2.png b/docs/blog/posts/img/build_okd_payload_2.png deleted file mode 100644 index fda9904b..00000000 Binary files a/docs/blog/posts/img/build_okd_payload_2.png and /dev/null differ diff --git a/docs/blog/posts/img/build_okd_payload_3.png b/docs/blog/posts/img/build_okd_payload_3.png deleted file mode 100644 index a831d5d2..00000000 Binary files a/docs/blog/posts/img/build_okd_payload_3.png and /dev/null differ diff --git a/docs/css/extra.css b/docs/css/extra.css index 5ab80621..cbfc7bff 100644 --- a/docs/css/extra.css +++ b/docs/css/extra.css @@ -2,23 +2,23 @@ [data-md-color-scheme=okd-dark] { --md-hue: 207; - --md-default-fg-color: hsla(var(--md-hue), 75%, 95%, 1); - --md-default-fg-color--light: hsla(var(--md-hue), 75%, 90%, 1); - --md-default-fg-color--lighter: hsla(var(--md-hue), 75%, 92%, 1); - --md-default-fg-color--lightest: hsla(var(--md-hue), 75%, 95%, 0.3); - --md-default-bg-color: hsla(var(--md-hue), 37%, 21%, 1); - --md-default-bg-color--light: hsla(var(--md-hue), 37%, 23%, 1); - --md-default-bg-color--lighter: hsla(var(--md-hue), 37%, 25%, 1); - --md-default-bg-color--lightest: hsla(var(--md-hue), 37%, 27%, 1); - --md-code-fg-color: hsla(var(--md-hue), 18%, 86%, 1); - --md-code-bg-color: hsla(var(--md-hue), 37%, 15%, 1); - --md-code-hl-color: hsla(var(--md-default-fg-color--lightest)); + --md-default-fg-color: hsla(var(--md-hue), 15%, 90%, 0.82); + --md-default-fg-color--light: hsla(var(--md-hue), 15%, 90%, 0.56); + --md-default-fg-color--lighter: hsla(var(--md-hue), 15%, 90%, 0.32); + --md-default-fg-color--lightest: hsla(var(--md-hue), 15%, 90%, 0.12); + --md-default-bg-color: hsla(var(--md-hue), 15%, 14%, 1); + --md-default-bg-color--light: hsla(var(--md-hue), 15%, 14%, 0.54); + --md-default-bg-color--lighter: hsla(var(--md-hue), 15%, 14%, 0.26); + --md-default-bg-color--lightest: hsla(var(--md-hue), 15%, 14%, 0.07); + --md-code-fg-color: hsla(var(--md-hue), 18%, 86%, 0.82); + --md-code-bg-color: hsla(var(--md-hue), 15%, 18%, 1); + --md-code-hl-color--light: #4287ff26; --md-code-hl-number-color: #e6695b; --md-code-hl-special-color: #f06090; --md-code-hl-function-color: #c973d9; --md-code-hl-constant-color: #9383e2; - --md-code-hl-keyword-color: #6791e0; - --md-code-hl-string-color: #2fb170; + --md-code-hl-keyword-color: #c6d5f1; + --md-code-hl-string-color: #7bcda4; --md-code-hl-name-color: var(--md-code-fg-color); --md-code-hl-operator-color: var(--md-default-fg-color--light); --md-code-hl-punctuation-color: var(--md-default-fg-color--light); @@ -26,14 +26,20 @@ --md-code-hl-generic-color: var(--md-default-fg-color--light); --md-code-hl-variable-color: var(--md-default-fg-color--light); --md-typeset-color: var(--md-default-fg-color); - --md-typeset-a-color: var(--md-primary-fg-color--light); - --md-typeset-mark-color: var(--md-default-fg-color--lightest); - --md-typeset-kbd-color: hsla(var(--md-hue), 15%, 94%, 1); - --md-typeset-kbd-accent-color: hsla(var(--md-hue), 15%, 94%, 1); + --md-typeset-a-color: var(--md-primary-fg-color); + --md-typeset-kbd-color: hsla(var(--md-hue), 15%, 90%, 0.12); + --md-typeset-kbd-accent-color: hsla(var(--md-hue), 15%, 90%, 0.2); --md-typeset-kbd-border-color: hsla(var(--md-hue), 15%, 14%, 1); - --md-admonition-bg-color: var(--md-default-bg-color--lighter); - --md-footer-bg-color: hsla(var(--md-hue), 15%, 12%, 1); - --md-footer-bg-color--dark: hsla(var(--md-hue), 15%, 10%, 1); + --md-typeset-mark-color: #4287ff4d; + --md-typeset-table-color: hsla(var(--md-hue), 15%, 95%, 0.12); + --md-typeset-table-color--light: hsla(var(--md-hue), 15%, 95%, 0.035); + --md-admonition-fg-color: var(--md-default-fg-color); + --md-admonition-bg-color: var(--md-default-bg-color); + --md-footer-bg-color: hsla(var(--md-hue), 15%, 10%, 0.87); + --md-footer-bg-color--dark: hsla(var(--md-hue), 15%, 8%, 1); + --md-shadow-z1: 0 0.2rem 0.5rem #0000000d, 0 0 0.05rem #0000001a; + --md-shadow-z2: 0 0.2rem 0.5rem #00000040, 0 0 0.05rem #00000040; + --md-shadow-z3: 0 0.2rem 0.5rem #0006, 0 0 0.05rem #00000059; } [data-md-color-primary=blue-grey] { @@ -48,24 +54,24 @@ [data-md-color-scheme=okd] { --md-hue: 207; - --md-default-fg-color: rgba(0, 0, 0, 0.87); - --md-default-fg-color--light: rgba(0, 0, 0, 0.54); - --md-default-fg-color--lighter: rgba(0, 0, 0, 0.32); - --md-default-fg-color--lightest: rgba(0, 0, 0, 0.07); - --md-default-bg-color: hsla(0, 0%, 85%, 1); - --md-default-bg-color--light: hsla(0, 0%, 60%, 1); - --md-default-bg-color--lighter: hsla(0, 0%, 70%, 1); - --md-default-bg-color--lightest: hsla(0, 0%, 91%, 1); + --md-default-fg-color: hsla(var(--md-hue), 44%, 7%, 0.87); + --md-default-fg-color--light: hsla(var(--md-hue), 44%, 7%, 0.54); + --md-default-fg-color--lighter: hsla(var(--md-hue), 44%, 7%, 0.32); + --md-default-fg-color--lightest: hsla(var(--md-hue), 44%, 7%, 0.07); + --md-default-bg-color: hsla(var(--md-hue), 44%, 96%, 0.87); + --md-default-bg-color--light: hsla(var(--md-hue), 44%, 96%, 0.54); + --md-default-bg-color--lighter: hsla(var(--md-hue), 44%, 96%, 0.32); + --md-default-bg-color--lightest: hsla(var(--md-hue), 4%, 96%, 0.07); --md-default-bg-color--white: hsla(0, 0%, 100%, 1); - --md-code-fg-color: hsla(var(--md-hue), 18%, 86%, 1); - --md-code-bg-color: hsla(var(--md-hue), 37%, 15%, 1); + --md-code-fg-color: hsla(var(--md-hue), 44%, 8%, 1); + --md-code-bg-color: hsla(var(--md-hue), 44%, 96%, 1); --md-code-hl-color: hsla(var(--md-default-fg-color--lightest)); - --md-code-hl-number-color: #e6695b; - --md-code-hl-special-color: #f06090; - --md-code-hl-function-color: #c973d9; - --md-code-hl-constant-color: #9383e2; - --md-code-hl-keyword-color: #6791e0; - --md-code-hl-string-color: #2fb170; + --md-code-hl-number-color: #c83727; + --md-code-hl-special-color: #e63c75; + --md-code-hl-function-color: #7e2e8c; + --md-code-hl-constant-color: #46378c; + --md-code-hl-keyword-color: #08317e; + --md-code-hl-string-color: #027e42; --md-code-hl-name-color: var(--md-code-fg-color); --md-code-hl-operator-color: var(--md-default-fg-color--light); --md-code-hl-punctuation-color: var(--md-default-fg-color--light); @@ -79,13 +85,14 @@ --md-typeset-kbd-color: hsla(var(--md-hue), 15%, 94%, 1); --md-typeset-kbd-accent-color: hsla(var(--md-hue), 15%, 94%, 1); --md-typeset-kbd-border-color: hsla(var(--md-hue), 15%, 14%, 1); - --md-admonition-bg-color: var(--md-default-bg-color--lightest); + --md-admonition-fg-color: var(--md-default-fg-color); + --md-admonition-bg-color: var(--md-default-bg-color); --md-footer-bg-color: hsla(var(--md-hue), 15%, 12%, 1); --md-footer-bg-color--dark: hsla(var(--md-hue), 15%, 10%, 1); } [data-md-color-primary='okd-blue'] { - --md-primary-fg-color: hsla(var(--md-hue), 37%, 21%, 1); + --md-primary-fg-color: hsla(var(--md-hue), 37%, 60%, 1); --md-primary-fg-color--light: hsla(var(--md-hue), 37%, 70%, 1); --md-primary-fg-color--dark: hsla(var(--md-hue), 37%, 16%, 1); --md-primary-bg-color: hsla(var(--md-hue), 37%, 95%, 1); @@ -1341,6 +1348,7 @@ footer { .footer_top:before { -webkit-transition-duration: 0.3s; + transition-duration: 0.3s; content: ''; right: 50%; margin-right: -30px; diff --git a/mkdocs.yml b/mkdocs.yml index fc8706d8..dd82f1fe 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -13,6 +13,23 @@ theme: logo: img/okd_logo_resized.svg favicon: img/okdLogo.png palette: + + # Palette toggle for light mode +# - media: "(prefers-color-scheme: light)" +# scheme: default +# toggle: +# icon: material/brightness-7 +# name: Switch to dark mode + + # Palette toggle for dark mode +# - media: "(prefers-color-scheme: dark)" +# scheme: slate +# toggle: +# icon: material/brightness-4 +# name: Switch to light mode +# +#----------------------------- +# - media: "(prefers-color-scheme: light)" scheme: okd toggle: @@ -83,6 +100,9 @@ plugins: - trimmer markdown_extensions: - attr_list + - pymdownx.emoji: + emoji_index: !!python/name:material.extensions.emoji.twemoji + emoji_generator: !!python/name:material.extensions.emoji.to_svg - admonition - toc: permalink: true @@ -93,7 +113,8 @@ markdown_extensions: class: mermaid format: !!python/name:pymdownx.superfences.fence_code_format - pymdownx.highlight - - pymdownx.tabbed + - pymdownx.tabbed: + alternate_style: true - pymdownx.details extra_css: - css/extra.css