Need to create the provenance file by hand as we mangle the name of the
chart archive. However, this also provides better user experience (for
the release manager) as gpg version 2.1 and later are supported.
Make the update-gh-pages.sh script to maintain a Helm charts repository
under charts/ subdirectory in gh-pages. The script now (always) scans
throught all release assets and injects any found Helm chart archives
into the Helm repo. In practice, new assets in all Github releases are
scanned and the Helm repo is updated on any update of the master or
release branches or on any new tags. Asset ids are tracked/cached in
order to avoid unnecessary downloads, but also, to capture any changes
in assets that were already merged in the repo index.
After this a user is able to do something like
$ helm repo add nfd http://kubernetes-sigs.github.io/node-feature-discovery/charts
...
$ helm repo update
...
$ helm install nfd/node-feature-discovery --namespace nfd --create-namespace --generate-name
...
This commit adds Helm chart for node-feature-discovery
Signed-off-by: Adrian Chiris <adrianc@nvidia.com>
Signed-off-by: Ivan Kolodiazhnyi <ikolodiazhny@nvidia.com>
Only update documentation if the version has been released (i.e. a git
tag corresponding the version we're updating exists) or it is for the
master branch. Prevents us from pointing users to documentation of an
unreleased version.
Also updates github workflow to fetch full commit history (including
tags) so that git describe works correctly.
Add a virtually empty ConfigMap that is mounted inside the workers.
Makes it easier to start customizing the worker deployment e.g. with just:
$ kubectl -n ${NFD_NS} edit configmap nfd-worker-conf
Create a new 'templates' make target for inserting the content of
nfd-worker.conf.example into the configmap spec of the templates. Thus,
'make templates' should be run whenever the example config is update.
Update the verify.sh prow script to check that the templates are up to
date.
This patch also streamlines the documentation about configuration
management, reflecting the changes.
Update update-gh-pages.sh to manage the index.html in the root of the
main gh-pages site. Make the index page to redirect to the documentation
of the latest stable version.
Change build configuration related to site baseurl and Jekyll output
directory a bit. Making it more coherent e.g. by removing the need to
override baseurl for 'site-serve' makefile target.
Only show the dynamic version menu in production environment where it's
available. Local (development) builds only show a stub version menu with
one item.
Also, fix the theme customization. Append version list items to the
correct element in html so that they are displayed correctly. Drop
unnecessary <div/>.
Make the list of available versions dynamic. The items displayed is now
generated with javascript. The parent directory of the site is supposed
to contain versions.js providing getVersionListItems() that returns the
available versions.
The update-gh-pages.sh script is modified to update/create versions.js
on every invocation. It simply lists all directories in the root
directory and adds them to the version list.
Add 'scripts/github/update-gh-pages.sh' for updating gh-pages branch.
This new script intended for github actions integration and builds the
html documentation from the currently checked-out commit and updates the
corresponding version subfolder in the gh-pages branch. The version is
taken from GITHUB_REF environment variable and defaults to 'master' if
the env var is empty. For testing purposes or manual updates the
subfolder can also be given directly as a command line argument.
Add 'scripts/test-infra/build-gh-pages.sh' for verifying that site
(gh-pages) builds successfully. This is intended for integration with
kubernetes test-infra.
Finally, add Github workflow for updating gh-pages. This job is run on
master and release branches plus all tags starting with letter 'v'.
We don't have a full git repo in the gcb builds so our version/tag magic
inside the makefile does not work. With this patch we get the version
information from the builder environment - fortunately we can do that by
simply stripping the date prefix from the _GIT_TAG variable. By
stripping the date of we match what our makefile does.
Let's just rely on our Makefile everywhere. Plus the previous version
was essentially broken as _PULL_BASE_REF env variable was not available
in testing jobs.
Use make for building our container image (through a new push-image.sh
script) instead of building directly with docker. This way we avoid the
container image tag naming hassle where we build and push the image on
"image-pushing" prow job and need to be able to reliably re-create the
same tag on the "testing" side for end-to-end tests. This also has the
advantage that the same mechanism (make) is used everywhere, i.e. in
image-pushing, testing and locally.
Add a new script for running end-to-end tests. Implement a Makefile rule
for polling the container image. We need this for prow as there is no
other way for syncing the jobs (e2e postsubmit job must wait until the
image-pushing job has built and published the image). This is
implemented in the Makefile as all the image-related variables are also
defined/available there.
Also, adapt the TravisCI config to use the new script.
