If package has deployment already, we should set package status to none instead of pending.
If we have package has source, we set status to pending.
If both source and deployment are empty, package marked as failure.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Making typed common cache so that we don't use wrong types
across set/get methods and more higher-level methods can be
defined for cache.
Currently, we are not able to operate over all keys of the cache
due to generic types.
I also removed code comments around the cache.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Add webhook server to tests
* fix config for webhoook service
* Fix logger in webhook manager
* Use interface for webhook manager
* single reference for router url
* Cleanup token code
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* used manager's Add function in more places
* exit when ctx.Done is received in archivePruner go routines
* fix manager tests
* fix data race
* added more gpm function in manager and removed manager from a util function
* closed unused channel and stopped ticker after context is done
* added log statements
* used context.Done inside function instead of stopper channel
- added manager to wait for all go routines to end before exit
- code refactor
- renamed Manafer to Interface and GoRoutineManager to GroupManager
- replaced some go routine calls with manager Add func
- added unit tests for manager
* skeleton for envtest fission
* Refactor code and add CLI test
* hack
* Update server test
* remove skip-ci for lint tests
* Pass client go storagesvc
* Add clientGen interface across code
* Fix storagesvc test
* Fix cmd client
* add retry in server test
* Fix concurrenct access to pool deployment
* Remove old executor test
* get rid of ginkgo/gomega
* disable flaky test
* flaky test
* revert ci change
* handle err from ParseBool
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Pranoy Kundu <pranoy1998k@gmail.com>
- Update kubernets version 1.23+
- Update post chart install notes with namespace info
- Update upgrade notes in chart
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
- added retainPods flag to take in the number of specialized pods to retain
- add retainPods in both the create function and update function command
- modify crd keys to be typed instead of string
- keep track of function generation in case of update function operation
- add delete handler function to make sure specialized pods are deleted in case function is deleted
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Signed-off-by: Pranoy Kundu <pranoy1998k@gmail.com>
Co-authored-by: Pranoy Kundu <pranoy1998k@gmail.com>
the FISSION_..._NAMESPACE environment variables are used by all services during init
to check if the CRDs are loaded.
Move them to the 'fission-resource-namespace' macro to ensure all services know the relavant namespaces.
Signed-off-by: Anthony King <anthony@datapane.com>
* Add fixes for failure in specialization
* reduce specialization in progress and remove expired requests from queue when specialization is timed out
* rename markSpecializationFailure and remove logger from the queue
* refactor clean up code in api.go and add test case for queue
Details:
- Cleanup svc waiting for the counter in the pool manager if specialization fails
- Cleanup active requests counter in pool manager if client exists the demand for function service while we have allocated function service
- Consider specialization timeout if pod ready timeout > specialization timeout in waiting for ready pod. We also consider if the request to choosePod is cancelled.
- We ensure if we have requests waiting for service requests but if there is no pod in the specialization we clean up those.
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Pranoy Kundu <pranoy1998k@gmail.com>
* add functionality to wait for specialization by keeping track of incoming requests
* format executor package
* fix required capacity to specialise new pod condition
* move handling concurrency logic into pool cache from executor
* remove unused methods and structs
* implement queue in to store the svc wait
* create a queue struct and its methods to handle concurrent inputs
* use newly created queue to store waiting for svc requests
* add waiting requests in queue and use them when a svc is ready
* set function to request in queue if the context is still alive
* remove concurrency approach to set svc for waiting requests
* update the active requests whenever requests from pool are assigned a svc
* add doc to define why the conditions exist
* remove unwanted params in strcut and clean up code
* set error while getting svc value if sum of specialization in progress and specialized is only more than concurrency limit
* remove duplicate functions and unnecessary values in struct
* close svc channel on set value and create constants for default concurrency and rpp
* get next value in queue in case context is timed out for fetched value
* remove specializationInProgress counter from pool cache
* return in case the queue is empty wihle setting func to svc
* test getSvcVaue and setSvcValue in poolcache
* add unit tests for GetConcurrent and GetRequestsPerPod methods
* reorder imports
* add fuzzy testing for getSVCValue and setSVCValue in poolcache
* restructure go mod file and update pool cache test cases
* Add tests and bug fixes
* refactor code and add test cases
* add svcWaiting check while setting svc value
---------
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* use flag FnExecutionTimeout instead of FnTestTimeout
* use flag FnExecutionTimeout instead of FnTestTimeout
* keep FnTestTimeout and FunctionTimeout both
* code review changes
Signed-off-by: Shubham Bansal <shubhambansaliimtgn@gmail.com>
---------
Signed-off-by: Shubham Bansal <shubhambansaliimtgn@gmail.com>
* changes to push images in github container registry
* reverting changes for helm chart to pass CI test
* use gitURL instead of whole URL
* use gitURL instead of whole URL
* added release process for docker.io
* removed trailing spaces
* added support for multi arch images in GHCR
* set authorization header for fission version and check command
* display warning if response status is unauthorize or forbidden
* passing context to http request
* create roles for custom resource in function and builder namespace
* Create roles for CR for builder in function and builder namespace
* convert warn to info to remove error stack trace
Merged pool cache package into fscache to avoid import cycle.
Also changed all types in pool cache from interface to specific
types.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Fix issue with updating time trigger without --cron flag
* Add check with ResourceVersion
* Change in UpdateFunc
Signed-off-by: Shubham Nazare <shubham4443@gmail.com>
Signed-off-by: Shubham Nazare <shubham4443@gmail.com>
* service account changes for fission-builder
* moved code into executor
* changed default timing to 30 min
* code refactor and add new roles for executor
* create role if serviceAccountCheck is enabled
* Use informerfactory across executor
* Run function informer for poolpodcontroller if istio enabled
* Use same namespace for secret as keda mqtriggers
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Remove cluster role references
* Convert secret/package getter cluster roles to role
* Remove all cluster role binding permissions
* Remove unwanted permission
* Try removing all RBAC-related code
* Remove additional constants
* Add functionality for service account checks
* Restrict permission across services
* Remove package informer factory from the executor
* Revert service account check code for now
* Skip adding roles in place of cluster roles
* Remove additional permission from the router
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* trigger test job to ensure backward compatibility
* update builder and function namespace in the CI test
* resolve namespace to show logs for fission-CLI
* export function-namespace variable
* Use a common script for an old and new test run
* Revert empty namespace values in the chart
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Replace all cluster roles with autogenerated namespaced roles
* Use cluster role only for preupgrade api extension permissions
* Correct role definition typos
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: shaunak_deshmukh <shaunak@infracloud.io>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Consider specific namespaces mentioned by the user in building informers in the executor
- Confimaps
- Secrets
- Deployments
- Services
- Pods
- Replicasets
We enable security context by default now, so that the fission pod do not have root access to the system.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* handle error condition in fission fn log command
* use the single stream for log exclude fetcher logs
* add all pods in the fn logs command
* update the previous stable version
* remove proxy to the controller for influxdb call
* stop running controller if influxdb flag turned true
* port-forward for influx DB
* remove controller dependency from test case
* port forward to influx DB if URL not provided by the user
* archive pruner test
* Backup Prometheus data from CI run
* use `kube-prometheus-stack` instead of `prometheus`
* Add dump-analyzer script
* Fix monitor helm chart values
* Update readme for dump-analyzer
* Disable grafana and alertmanager
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* handle error condition in fission fn log command
* use single stream for log exclude fetcher logs
* add all-pods in fn logs command
* update previous stable version
* add controller enablement flag
* throw an error if service not found
* add logs from Kubernetes in function log command
* pass context in function param
* add pod-namespace in function log command
* pass context in function param
* search for the pod in fn ns in the test
Currently, we create Fission resources in the default namespace, function-related resources are created in the fission-function namespace, whereas builder resources are created in the fission-builder namespace. This causes confusion for a lot of users.
In this fix, we allow the user to set the function and builder namespace empty so that function and builder resources are created in the same namespace as the function resource always.
If the user desires older behaviour they can functionNamespace and builderNamespace the same previous before the upgrade.
* use default namespace for fission function and builder
* support for existing fission namespaces
* Replace builder and function namespace with template
* Fix namespace creation template
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Convert ClusterRoles to Roles for all components for multiple namespaces
* Added templates for rules and role generator to dynamically generate roles for each component
* Fix role-generator component templating
* Enable namespaces variable for preupgradechecks
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: shaunak_deshmukh <shaunak@infracloud.io>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Add variables for function/builder namespace in the test
* Allow different namespaces in integration tests
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Use the Kubernetes and Fission Client from CLI instead of Controller API.
This removes port-forwarding for the controller across Fission CLI mostly.
* Use configurable client in CLI
* Move resource namespace under cmd client
* use server to get fission version
* get archive with URL
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
We allow functions to refer to configmap/secrets. We are monitoring all namespaces for config maps and secrets and also allow cross-namespace references.
This fix monitors configmaps/secret updates in specific namespaces. Also, we ignore cross-namespace references for configmap/secret updates.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* added unit test for setup role binding method
* changes to throw an error in case of mismatch in cluster role name
* changes to add a check for role kind
* Role and RoleBinding for fission-fetcher and fission-builder can be created in additional namespaces
* Added template file for fetcher and builder role and rolebinding
This PR moves fission CLI as closer as possible to kubectl command behaviour. We have improved namespace handling behaviour across CLI.
* add namespace param for fn and env
* use common fn for ns check
* update validation
* default namespace for httpTrigger, env and package, config and triggers
* use default ns
* add namespace filter to spec
* add forceNamespace flag
* set current namespace
* add default namespace in config
* add namespace specific destroy
* add all namespace in the list of resources
* add namespace as global tag
* use %s instead of %v
* add test cases for namespace
* use ns in get all functions
* Separate service accounts for each component
* Permission changes per component
* Fixed fluentbit permissions
* added hooks to pre-upgrade service account and role
* Adjusted hook weights for pre-upgrade hook
* Replaced * with explicit permissions
Added properties to configure object reaper interval, global and specific to exec type.
OBJECT_REAPER_INTERVAL - global
NEWDEPLOY_OBJECT_REAPER_INTERVAL - for new deploy type
CONTAINER_OBJECT_REAPER_INTERVAL - for container type
POOLMGR_OBJECT_REAPER_INTERVAL - for poolmgr
These changes have specifically been made for Kafka connector. This will expose a new metric named `fission_mqt_message_lag`, which will show a number of messages lag per topic and partition.
We can use this metric in the auto-scaling of the pod for the new deploy type executor function. While creating a new deploy function we need to add hpa metrics of external type inside the function definition.
* allow two HTTP triggers with no URL and different prefix
* update dependency
* Fix controller existing tests
* Ensure namespace cleanup in API test
* update test cases
* handle error conditions in test
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Add grafana dashboards and configmap creation
* Fix Data source, job and template rules
* Add units to all panels
* fix units and fix linting issues
* Enable verbose linting for dashboards
Co-authored-by: shaunak_deshmukh <shaunak@infracloud.io>
Configmap inside pods for newdeploy and pool manager executor type were not being updated if the user update the configmap.
This fix will help to update the pods for both executor type with new configmap. As per the changes if there is any configmap update then pods will get restarted for both executor type and then it will refer new configmap.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Updated all Go language dependencies to latest version available
* Formatted all files as per gofmt
* Update Golangci-lint version to 1.48.0
* Updated action version wherer application in Github workflows
* Updated Kubernetes version to latest available
* Remove "io/ioutil" references and replace with "io"/"os"
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
1. Use websocket support introduced in Openetelemetry Librarries
2. Use propagators settings introduced in Opentelemetry Go SDK
3. Use samplers settings introduced in Openetelemetry Go SDK
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
The users can now set the pod spec for builder and fn pods via helm chart.
Currently we have set some default securitycontext for the pods. Before there were no permissions set and the user would by default enter root when kubectl exec into pod. Now the permissions have been set and the user will not be able to access root directory in poolmgr and newdeploy pods.
* Add API for listing storage service archives
If id is mentioned we allow user to download specific
archive. If id is not mentioned we list all archives
present with storage service.
This will allow us to build CLI with storage service
and help users to debug storage service.
* Added commands for storagesvc cli and functionalities
* Reusing code and added geturl and download.
* Fixed geturl for localstorage.
* Fixed description of fission archive command
* Added unit tests for function getstorageurl
* Added integration test for archive cli
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* allow buildcmd command to process arguments
* Add unit tests for builder with different scenarios
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Add pre-check flag to root cmd
* Make precheck flag optional
* Remove pre from global optional flag
Signed-off-by: Shubham Nazare <shubham4443@gmail.com>
Following component has been updated with securityContext -
1. buildermgr
2. controller
3. executor
4. kubewatcher
5. router
6. timer
7. storagesvc
* Removed the security context from fetcher as per the offline discussion
* Add support for custom metrics for HPA
* Cleanup TargetCPUPercent references from possible places
* HPA v2beta has 80% default cpu limit if not set
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Migrate HPA v1 to v2beta2
HPA v2beta2 is defined and supported from 1.19+ onwards.
Also HPA v2 is stable from 1.23 onwards. As we support 1.19+
onwards using HPA v2beta2.
This change is base for custom metrics support we want to add
later by modifying Function spec.
* Add unit tests for hpa operations
* Use constants instead of strings
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Use latest goreleaser with GOAMD64 support
* Update Go version to 1.18.1
* Hardcode GOAMD64 in cli install
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Created separate file for authmiddleware fn
* Optimize auth login and middleware
* Added unittests for authmiddleware
* Fixed authURL
* Removed featureConfig as global variable
* Fix integration test according to examples repo changes
* Fix integration test path for go module-example
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Using interface makes it easy to create a fake client and unit test
a specific portion of the code. We should be able to more write unit
test and increase coverage of code with this change.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
In pool pod controller we were using pool namespace
rather than pod namespace in cleanup which was causing
issue in few scenarios. Using pod namespace now instead.
Also add unit test for scenario which was failing.
Using kubernetes client interface now across instead of
kubernetes ClientSet for testing.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Defining httpserver package to capture httpserver shutdown and
introduces uniform running of http server across codebase.
* Add unit tests for httpserver
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
- Enabled metrics in storagesvc, buildermgr and controller.
- Added a middleware in storagesvc, router, executor and controller to monitor total number of http requests, each request's duration and number of requests that are currently being served. These requests can be filtered on their path, method or statuscode.
- Removed functionCallDuration and functionCallResponseSize metrics from router.
- Removed funcAliveSummary, funcIsAlive, funcReapTime and idleTime metrics.
- Replaced function calls for collecting metrics to direct metric calls.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Currently we dial on localport and wait until, port forwarding
is done. Using channel instead from forwarder to wait explicitly.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
We are removing Fission deprecated Azure Storage Queue connector and
planning to adopt Keda going forward to have better
delegated functionality and more rich support.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
We are removing Fission deprecated Nats connector and
planning to adopt Keda going forward to have better
delegated functionality and more rich support.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
We should avoid tap service call to executor if service URL retrieved from executor is empty.
Added sanity checks to ensure that.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
- Use mqtrigger watch instead of polling mqtrigger every 5 seconds
- Added metrics to monitor no of subscriptions, and no of messages per subscription
- Add standard go metrics exported by prometheus
- Enable prometheus discovery for mqtrigger pod
- Optimized mqtrigger manager cache
- Add unit tests for mqtrigger cache
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Update Go version to 1.17 and dependencies
* Changes in ProbeHandler and LifeCycleHandler
* Update CRD definitions
* Update Go version to 1.17 in Github Actions
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Removing Prometheus dependency from fission chart
* User should install their own Prometheus installation
* Install Prometheus chart in Github CI workflow
* Change Prometheus query logging to debug
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
This change mainly fixes few things around router and executor
exposed metrices.
1. We are trying to follow standard in metric names.
2. Lables such as namespace are colliding with kube-prometheus standards
so they are getting relabled to exported_namespace. Added function prefix
to resolve this.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* fix helm templating on resources of router deployment
* add resources attribute to other fission deployments
Co-authored-by: crmendes <carlos.mendes@kelvininc.com>
* Change RBAC resource names work for multiple Fission release
* Fetch secret configmap and package cluster role based on the release name
* Remove default namespace hardcoding from helm chart
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* If a bucket already exists with the same name, allow the user to use that one
* Abstracted create or get a storage container
* Check err when the con is empty and return container name with error
- Currently, fission components don't handle shutdown signals.
So we don't get any to do the required cleanup before the fission process
exits. Adding signal capture process with cancelling context so
that all dependent processes stop working when the process gets term
signal.
- Set log level to error in otel shutdown function
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Currently when any of fission component exists, we fail to sync
log as logger.Sync is not called before exiting.
Restructured code so that we can logger.Sync before existing from
the fission bundle component execution.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Reactored ready pod controller code to user lister and cache sync checks,
so that we avoid querying lister if cache is not synced in choodPod function.
Also, as noticied in #2258 we were initializing workqueue in goroutine
which was causing nil pointer reference. We have moved it out of goroutine
and kept specific parts in goroutine.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Currently default pod termination logs go to /dev/termination-log.
With CI we need to change customize path somewhere to /var/log for
exporting logs with the kind export logs command.
Setting FallbackToLogsOnError as termination policy for skaffold.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
In Fission CI as well in a couple of scenarios, noticed Fission pods
getting preempted when Function pods are getting created. As both
Fission components and function pods have the same priority class
fission component pods might get preempted. It to be recommended to
set higher priority class for components such as Fission router, executor,
controller so that Fission functioning doesn't get disrupted.
Most of the Fission components work fine with restart except the executor. So
user should set priorityClass for Fission executor.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
- New flag `--specignore` has been added for command fission spec [list | validate | apply | destroy]
- This flag is optional.
- The default spec ignore file name is `.specignore`, if the flag is not used
- The spec ignore file existence will be checked in the `--specdir` path
- If spec ignore file is passed to the flag, with a name other than .specignore and if it does not exist in the `--specdir` path then an error will be returned.
- `--specdir` will be the root path against which the patterns will be evaluated
- The behaviour of the spec ignore file will be similar to .gitignore (only for yml and yaml files). For reference: http://git-scm.com/docs/gitignore
We would like to deprecate Fission Nats Integration and recommend
user to use Fission Keda Nats connector to handle Keda events.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
The io/ioutil package has been deprecated as of Go 1.16, see
https://golang.org/doc/go1.16#ioutil. This commit replaces the existing
io/ioutil functions with their new definitions in io and os packages.
Signed-off-by: Eng Zer Jun <engzerjun@gmail.com>
Added options to allow disabling of pre-upgrade checks,
also providing options to mention image and image tag
for pre-upgrade.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Sync a few files from fission-all to fission-core chart
* Change values in fission-all chart
We keep the following components by default disabled now, which were enabled by default earlier.
1. nats - Fission Nats integration
2. influxdb - Influxdb and logger component
3. prometheus - Prometheus disabled by default
4. canaryDeployment - Disabled by default
This change reduces the need for a fission-core chart and we can configure
values of fission-all so that it can provide the behaviour of fission-all
as well as fission-core.
* Remove fission-core chart
* Add README in the fission-all chart
* Rename clusterrolebinding fission-crd to fission-cr-admin
* Add icon and sources in helm chart
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* security: Update go-uuid to recommended version
* security: Update mholt/archiver dep to recommended version
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Samplers: Check PR/helm values for supported types
* Propagators: Check PR/helm values for supported types
* Added tracing support via fission CLI
* Use parentbased_traceidratio as default sampler with 0.1 ratio
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Capture important open telemetry events with span in fission
* Add context to missing HTTP calls
* Add Trace ID in logs
* capture trace id in the proxy handler function
* Always registry tracer to get traceID
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
When fetch request is received by fetcher, it fetches
package information. Checking if package resource version mentioned
in fetch req matches with one received. Adding warning for now,
in future we need to ensure we give error if resource version
are not matching.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
In upgrade tests, sometimes in race condition pool manager podlister
takes time to sync in which case, poolpodcontrolller get nil reference
for gpm.podLister. Passing podInformer to poolpodcontroller so that
we wait for podInformer cache to sync.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
With addition of prefix based routes in 1.13.1, we have turned
all internal routes prefix based. This is causing wrong responses
in functions names with common prefixes such as `hello-world` and
`hello-world-consumer`. This patch fixes it where we add a fix route
for function name and prefix path for function name with `/`.
We improve overall prefix path handing with fix and prevent breakage
for existing flow.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Using controller-runtime zap integration which is aware of Kubernetesobjects and logs only name+namespace of the object when complete runtime.Object compatible type is given to logger.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Signed-off-by: Sanket Sudake sanketsudake@gmail.com
- Use informers and listers in executors
- Passing context properly in pool manager executor
- Environment updates in the pool manager would not cause updates in the deployment
- Environment update minimizing downtime
- Use replicaset controller and environment delete triggers to cleanup specialized pods
Generally using typed informers is more standard practise
than using SharedIndexInformer(SII) implicity. SII also lack
listers provided by informer factory and few other high level
abstractions.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Currently most of informers used in Fission are using resync
period of 30sec which is quite low and causes lot of disturbances
in overall system. Since informers already have watchers which would
be delivering events to the handlers. If any handlers require lower
sync period they should register handler with `AddEventHandlersWithResyncPeriod`
instead of we generaling informer.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* add opentracing section and otelCollectorEndpoint
* initialize OTLP exporter
* pkg/controller: changes for context propagation
* pkg/executor: changes for context propagation
* pkg/fetcher: changes for context propagation
* pkg/router: changes for context propagation
* pkg/storagesvc: changes for context propagation
* set no default value for otel collector endpoint
* update readme and add notes to charts
* move common code to pkg/utils/otel
* adding fn and env as attributes
* don't use otelhttp transport for websocket
* URL ignore with common filter UrlsToIgnore
Note: The web socket example does not work when using OTEL HTTP. Here is an issue related to that on open-telemetry/opentelemetry-js-contrib.
Signed-off-by: Gaurav Gahlot <gauravgahlot0107@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
The patch adds few improvements in pool manager and adds better
function composability by reorganizing code.
1. Added created status in get pool call
2. Improved logging in certain areas and having logger per component
3. Separated deployment-specific code in diff file for extensibility
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Currently when we update env, even if we dont have newdeploy related
functions env is getting is getting triggered. Added filter in finding
related functions to avoid this behaviour.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Change Ingress version from v1beta1 to v1 for K8s 1.22+ compatibility
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Minor fix
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
PR adds a new executortype which supports running containers as functions. New CLI under functions is added to create container as functions.
Co-authored-by: Harsh Thakur <harshthakur9030@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
1. Support for adding labels and annotations to functions & environment via fission CLI through create & update command.
2. Change ensures labels and annotations assigned to the environment would reflect on pods created via executor type pool manager and new deploy.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Retrieve pod metrics only if metrics server is running
Currently we query pod metrics every 30 sec which floods executor logs,
added check which confirms if metrics server is running then only we start
querying pod metrics for identifying CPU utilization.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Fixed couple of typos and misspells with Go CI
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Remove unnecessary conversions with Go CI
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* add multi env and multi k8s support on integraation tests
* test workflow
* test workflow
* test workflow
* remove test branch name
* correct kind action with image and version
* use same kind version as per kind images
* use OS as ubuntu-latest
* fetch upstream
* add .github/workflows to paths
* resolve conflicts
* make kindimage appear first on workflow
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Correct release name in release script for non helm install
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Increase test timeout to 20 minutes
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Enable codeql for master only
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Added GCP PubSub Image, enabled Keda by default and updated versions of all Keda connector images
Signed-off-by: Vishal Biyani <vrbiyani@gmail.com>
* Fixed the hyphens, it's been long since I have written Helm templates :)
Signed-off-by: Vishal Biyani <vrbiyani@gmail.com>
* Fixed the hyphens, it's been long since I have written Helm templates :)
Signed-off-by: Vishal Biyani <vrbiyani@gmail.com>
* Update charts/fission-all/values.yaml
Co-authored-by: Harsh Thakur <harshthakur9030@gmail.com>
* Update charts/fission-core/values.yaml
Co-authored-by: Harsh Thakur <harshthakur9030@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Harsh Thakur <harshthakur9030@gmail.com>
* Add a SharedIndexInformer for services and deployments to NewDeploy executor.
This brings the NewDeploy executor behaviour into sync with GenericPoolManager behaviour
by caching Kubernetes services and deployments used in per-request function validation.
* Create informers in executer by executor label
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: James Sinclair <irgeek@btc.com.au>
* Enable prefix based routing
Signed-off-by: Harsh Thakur <harshthakur9030@gmail.com>
* Optimize checking condition
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Disable few tests
* disable router modification for now
* run code generator
* Collect fission dump in CI
* Enable all tests back
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Remove unwanted code
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Add prefix support at more places and couple of todo's
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Few more changes
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Improve function trim support
* Support for prefix based urls in fission function test
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* multi route for fission function test
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Improve validations in trigger creations
* Adjust leading / in url from fission
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
* Change suburl to subpath for function test
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
* Add a warning if spec is applied on a dirty worktree
* Update go dependencies after rebase
* Use the console package for showing the warning
* Fix merge conflicts
* Handle errors and use better messages
Co-authored-by: Sanket Sudake <sanketsudake@gmail.com>
Since we recently migrated all fission examples to fission/examples repository, we need to change
respective references.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
We are facing issue in CI for multiple PRs due to mlock. It depends on kernel version or ulimit. Trying to switch to latest go version from 1.14 and see if it helps!
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Series are sorted internal by "order by", but the set of all series returned is not. Tried some ways to sort completely on database, found no way .. client side sort works at least
Co-authored-by: Vishal <vishal-biyani@users.noreply.github.com>
Adding once only execution pattern to pool manager based functions. This is for use cases where you don't want to share the samne pod for another execution instance!
In test_mqtrigger.sh and test_mqtrigger_error.sh tests, we timeout program
if not received right output. Ensuring we capture timeout signal and do program
cleanup accordingly. Also printing due to which signal program failed.
Signed-off-by: Sanket Sudake <sanketsudake@gmail.com>
Moved out environments and examples out of main Fission repo to their own repo. This is to allow changes to environment releases to be independent of main Fission releases.
Websocket event support for cleaning up pods only after WS connection is terminated. The support for websocket is right now in the environment itself and router simply acts as a proxy for WS communication!
Increase the default concurrency to 500 from 5 set in the function. Usually, it is good to error on the higher side and if needed, users can always fine-tune it to their needs.
This feature enables routing more than one request to a pod at the same time. This is the first draft of the work and might involve more optimizations later.
Passing information of function from router to executor is more efficient than calling the K8S API. This change does that instead of passing only metadata and then executor calling the K8S API again.
A ready pod which can be specialized was fetched for every function earlier, this has been changed to a queue and cache implementation in client-go to improve performance.
Poolmanager when tested at high load had some issues and this PR fixes one set of them which were found so far.
Co-authored-by: Vishal <vishal-biyani@users.noreply.github.com>
Concurrency in the pool manager allows specializing pods concurrently based on a specified limit.
Co-authored-by: Vishal <vishal-biyani@users.noreply.github.com>
Attribute enableServiceLinks can be now configured in PodSpec so that environment variables are not injected in function pods and DNS is used for discovery
This PR let the controller returns the detail error message
of kubernetes error which makes users understand what's
happening instead of meanless error msg.
This PR changes the behavior of controller API which
wrongly exposes sensitive data to the client. Now, the
API only returns success if secret/configmap exists;
otherwise, an error will be returned.
In some cases, creating a package and querying the package info
immediately the Kubernetes API server will return "not found"
error. So retry the query again after some time.
In some cases (#1384), users may want to access the file in the directory of deploy archive, however, we use the function UID name as the directory name and make it difficult for users to use as they don't know the real path of the directory.
This PR uses the fix name "deployarchive" to make things easier.
If the user applies package YAML file has no status field,
the package won't be able to be compiled or deployed due
to lack of status. This PR aims to add a check at buildermgr
to set initial package status to those packages.
Executor wrongly deletes role bindings if the user
creates an environment in the reserved namespaces. This
PR is a quick fix to solve the problem by checking if
an environment is under reserved namespaces.
This PR adds a fake controller client for local CLI operations like
offline spec generation or for unit test purposes. The fake client
now only implements the "Version()" function and more functions
will be implemented once we figure out how to achieve the goals
mentioned above.
The root cause of the problem is that eagerPoolCreator
tries to create the deployment when the poolmanager
is trying to delete it. To avoid this, start eager pool
creator after executor starts serving requests.
Adding fission spec list functionality. It lists Functions, Environment, Packages, HTTPTrigger, MessageQueueTriggers, Canary Config, TimeTrigger, KubeWatch created by an application specification.
The 3rd party package version used by the go server
may be different from the one in the user's source code
and will cause plugin version mismatched. Hence, we
should never import any external packages except the
Fission or built-in packages.
This PR replaces all 3rd-party packages with built-in packages.
This PR adds an interface for controller API client, it allows us to
implement mock API client for unit testing with ease and we are
able to generate spec file without accessing the real Fission server.
The pod template is embedded inside the deployment. So if
the pod annotation contains instance-id, the deployment
will get updated and thus triggers a rolling update whenever
a new executor starts which is unwanted.
After this PR, poolmanager will patches instance-id when a
pod is chosen for a function.
For newdeploy, unlike poolmanager manages the lifecycle
of function pod directly, newdeploy is only responsible
to create the deployment so we append instance-id to top-
level controller (deployment) only.
We used to update timestamp in the deployment environment field
in order to trigger a rolling update when the function referenced
resources get updated. However, use timestamp means we are not
able to avoid triggering a rolling update when executor tries to adopt
orphaned deployment due to timestamp changed which is unwanted.
In order to let executor adopt deployment without triggering a rolling
update, we need an identical way to get a value that can reflect res-
ources changed without affecting by time.
To achieve this goal, the sum of the resource version of all referenced
resources is a good fit for our scenario since the sum of the resource
version is always the same as long as no resources changed.
When a new executor starts up, it adopts the orphan kubernetes resources created
by the old executor instance. However, the adopted resource won't reflect the changes
come with the new executor, for example, the fetcher image inside won't be changed.
To solve this, executor updates the resource spec (HPA/Deployment/Service) with the
latest resources spec. By doing this, we can prevent the inconsistency between resources
created by different executor instance, also minimizes the impact on users.
Previously, once the executor is deleted for reasons (like upgrade or cluster scale-in),
the new executor deletes all existing resources created by the old executor and creates
new one. This mechanism becomes a problem when there are requests connecting to the
existing pods. Also in the worst case, the cluster may not have enough resources to create
new pods and cause service downtime.
This PR let each executor type adopts existing resources before starting the executor
API services, and so the alive connections won't experience failure. However, the requests
send to the function that doesn't have alive function pods will still fail due to the
executor is in bootstrapping.
The pool manager keeps terminating function pod periodically even there are
traffic to the function. The root cause is that executor, poolmgr, newdeploy
manage their own functionServiceCache separately. And when router taps a
function, executor updates the access time of the function service entry in its
own cache without notifying executor types to do the update as well. Hence,
the access time of function service entry in poolmanager cache never gets updated.
Due to the access time never gets updated, the idle pod reaper in poolmanager
then thinks the function pod is in idle state and recycle it.
This PR removes the cache in executor itself, and when router tries to tap a function,
executor will call executor type to tap the function and update access time.
The router taps function service one by one which is inefficient and
increases the burden of executor. This PR aggregates all requests into
one to solve the problem mentioned above.
When a function is created before the creation of the environment it's used, the newdeploy will not be able to create kube objs. Hence no function service record is inserted into the cache.
When getFuncSvc is called, the newdeploy tries to find the record in service cache in order to create kube objs with the same name used in previous kubeobjs creation. However, due to no record in the cache, a NotFound error is returned directly and causes the problem. To solve this, we use fn meta UID to ensure we always get the same obj name instead of getting it from the cache.
If the context of request is closed before ReverseProxy finishing writing
a huge response body to the response writer, the client will only receive
a truncated response body.
To solve this, move the context cancel after ReverseProxy finished.
To keep archive creation implementation simple and prevent any
confusion, we decided to remove `--keepurl` flag and embed URL
directly without downloading the file from it . In this way, we can
ensure consistent behavior in either package creation or spec file
creation. Also, it increases the portability of spec file.
1. The records are stored in redis which is not migratable to another cluster for the testing purposes.
2. Some of the requests fields are not recorded.
3. People should consider using https://github.com/buger/goreplay which is an existing mature and well-tested solution for testing purposes.
The function implementations of controller client package are
inconsistent. This PR lets functions reuse the functions
that already implemented and able to set additional headers to
request.
When `fn test` failed to retrieve logs from the function
pod, it turns to query logs from the log database. However,
the logdb type flag is not set to `fn test`, hence the logdb
type is empty (even without default value) and cause `fn logs`
returns an error due to unable to find the corresponding log
database type.
This PR adds logdb type flag to `fn test` to resolve the problem.
Jaeger preserves the trace data of router healthz endpoints
which is not so helpful for monitoring function metrics and
consumes storage to store such trace data.
This PR uses `GetStartOptions` to examine the request's path and
check if it's a request to healthz endpoint. If yes, skip and not
to trace it.
To follow 12-factor app rules, make jaeger collector endpoint
as an environment variable instead of CLI args. It's easier to
replace the value in different deployments. Also, we can utilize
valueFrom to get value from the configmap.
The helm pre-upgrade check failed due to the program tries to
check whether a multierr is a nil pointer instead of errors it contains.
This PR changes the way the program checks multierr in order not to block the upgrade.
Helm treats the single line "extraCoreComponentPodConfig" in
values.yaml as a key value pair config.
```
extraCoreComponentPodConfig:
```
And when a user tries to install helm with providing config
like following, it failed.
```
extraCoreComponentPodConfig:
nodeSelector:
serverless: fission
```
The root cause is that helm treats config in default values.yaml
and providing config as two different types of config, which is
key-value vs. value table. And so it's unable for helm to merge these
two configs even with the same key name.
This PR comments out the single line config in default values.yaml
to prevent the issue.
Before this PR, CLI functions fatal out when encountering error
instead of returning it. Such behavior makes it hard to reuse
the functions nor writing unit tests. This PR aims to make functions
return errors instead of error out.
Istio sidecar proxy blocks all requests sent through the reverse proxy
to the target service if the request.Host is not properly set to the
internal target service host. This PR sets the target service hosts
before establishing the proxy for the client in order to pass the
Istio sidecar proxy check.
Tensorflow Serving supports three kinds of API: predict, classify, regress. In order to fully support possible API types, this PR adds code to split the entry point with separator ":" to get model name and the API type separately. And append the API type to proxy URL when receiving the requests.
$ fission fn create --name t1 --pkg <pkg name> \
--env tensorflow --entrypoint "half_plus_two:regress"
The utility function GetMetadata uses wrong flag text to get the resource namespace and could cause the wrong results returned from the API server. This PR changes the function signature that allows users to pass in the flag text in order to get the correct value.
In the case of large files, it takes a long time for the user to download
the source from the URL and upload it to StorgeSvc through CLI.
This PR allows a user to use URL as the function source when creating a function
and provides a new flag "--keeparchiveurl" to let the user to decided
whether the CLI should download the file first or store the file URL in the
archive directly. If "--keeparchiveurl" is true, then no checksum will be
generated, it's the user's responsibility to ensure the file won't be changed.
When a function with executor type newdeploy got created, Newdeploy
is expected to create deployment/HPA/service for it and insert serviceEntry
to the cache for later use. Once clients call the function, newdeploy returns
the serviceEntry to the router.
However, the log shows that the newdeploy was unable to find the entry and
prints "Resource not found - key 'xxx' not found". The root cause is that the
informer controller instead of processing items in parallel, it dispatches XXFunc
to process items one by one. So if there is any problem during the creation of the
kubernetes resource, it takes a longer time to process the next item and hence
the serviceEntry was not inserted before clients call the function.
This PR lets the newdeploy to process items in extra goroutines instead of blocking
the process loop. It's a workaround to solve the problem above, we should consider
using workqueue to solve it in the future.
Encoded path means the URL path contains encoded string like "/foo%2Fbar".
Gorilla/Mux by default doesn't enable encoded path support, you need to enable
it when initializing the router.
This PR adds a new environment variable USE_ENCODED_PATH to the router
deployment to enable encoded path support.
If a user deploys fission in the namespace which is different from the one in the single YAML file generated by helm, fission components won't be able to talk to each other due to the wrong namespace appends after the service address.
This PR adds --namespace when generating the YAML file to prevent the mismatch problem.
ReplicaSet generated by Deployment distributes pods to nodes based
on nodes resource usage, which means in some cases the newly created
pods may be assigned to only a few nodes. The requests will go to the
same node if there multiple pods on it and may increase the node
resource usage and overall request latency.
To solve the problem mentioned above, this PR allows users to deploy
the router as DaemonSet so that we can distribute requests across all
nodes for better workload distribution and lower latency.
The merge function executor used wasn't merge container correctly, and it
didn't merge all fields in spec except volumeMount & Env which confused people.
To apply the user-configured container correctly, this PR changes the way of merge
and follows rules:
1. Slices are merged and return an error if the elements in the slice have name conflicts.
2. Maps are merged, the value of map of dst container are overridden if the key is the same.
3. The rest of the fields of dst container are overridden directly.
In 1.9, kubernetes prompted Deployment to apps/v1 and finally deprecated
extensions/v1beta1 support in 1.16. Users will see the following error message
in log when fission components try to submit Deployment to the k8s API server
and specify extensions/v1beta1 as API group.
error: unable to recognize "deployment": no matches for kind "Deployment" in version "extensions/v1beta1"
This PR updates call to k8s API server and apiKind in chart files to avoid fission failure in 1.16.
Router readiness probe failed due to kubelet cannot find router healthz endpoint.
This is caused that the healthz endpoint is added only when there is any update request
send to the updateRouterRequestChannel, and makes router failed.
This PR sends an update request right before the router is started to avoid the problem.
The router prints error no matter what error type it is.
It's useful for troubleshooting, however, it also prints
the context canceled error, which means that users abort
request before reply and its really normal nowadays. Also,
the router returns 502 if error is not nil and may confused
client if it's a timeout error.
To solve these problems, this PR adds an error handler to
reverse proxy to examine the return error and change the
status code when needed.
Previously, the spec doesn't update the package status if nothing
in the spec file changed. Due to this, the failed package will
always stay in the failed state.
This PR adds a check to see whether a package is in the failed state.
If yes, then changes the state to pending for builder manager to rebuild it.
Previously, a user has to delete HTTP triggers point to
the same function one by one. This PR adds new flag --function
to list & delete commands. So that user can delete or list all
triggers with the same function. However, this feature is not
working for triggers with canary deployment setup.
For each ingress controller, the format of ingress host,
path and annotations are different. To support different
kinds of controller, this PR adds new ingress config field
to http trigger spec. A user can set annotations, host and
path based on the type of underlying ingress controller
with CLI.
Command example:
fission route create --name foo \
--url /foo/{bar} --function foofn --createingress \
--ingressannotation "nginx.ingress.kubernetes.io/ssl-redirect=false" \
--ingressannotation "nginx.ingress.kubernetes.io/use-regex=true" \
--ingressrule "*=/foo/*"
* Add specializationtimeout flag to function create/update
* Set specialization timeout of 120 seconds if not present
* Add default newdeploy timeout for rest of the test cases
* Comment out specialization timeout in validations for compatibility
* Add warning if specializationtimeout is lower than default value
This fix allows the empty repository tag in values.yaml file. The changes are done in the templates of deployment and fluentbit where repository tag will be added in the docker image name only when specified with some value in case of empty repository tag image name contain the name of image and tag only.
* Config and secret change to invoke function update
* Added recycle function for pool manager as well - where it recycles the specialized pods
* Switched to rolling update of pods and env variable based change instead of deleting pods in new deploy executor
This PR removes not so useful logs and changes most of Info level
log to Debug/Error level in hot path while preserving some of them
that is helpful for troubleshooting.
Currently, only one CI build can be started at the same time due to we only have only one testing cluster. This PR aims to enable multiple concurrent builds can be triggered to reduce the waiting time for CI builds. The major changes listed below:
1. Each build generate unique images for testing and debugging
2. Check whether the testing cluster is being used by another build.
3. Cache docker image & go mod after build finished
4. Improve dockerfiles for reusing docker build cache
* Use terraform to manage ci cluster. Upgrade ci cluster to 1.13
* Upgrade helm version
* Do not break the test if no previous resources
* Do not skip install helm if helm is old version
* Add support for setting nodeSelector/affinity/tolerations on all deployments of fission components.
* Add extraCoreComponmentPodConfig helm value to allow setting of affinty/tolerations/nodeSelectors/etc on core pods
The prometheus server may not come up in a short time or when a cluster doesn’t have a storage class config. Because of this, the connectivity test will increase controller initialization time and so the controller will fail at readiness probe detection. Since we don’t want to delay the time that controller comes up also canary config manager prints error log when it failed at connecting to prometheus server, remove the connectivity test here.
Consolidates the addition of the fetcher container to the pod into a new type FetcherConfig and takes care of serviceAccountName if not set. Also added PreStop lifecycle handler if pod set TerminationGracePeriodSeconds
Currently the implementation of the CLI (or any Fission component) specifies any timeout on
the fission fn test functionality. If a user function or environment does not specify any
timeout the command will stall. Nor is there any parameter to set a timeout if the user
wanted to.
This change sets the sensible default for the timeout to 30 seconds, to avoid new
users having to figure this out the hard way. The alternative could be to set the timeout to
0 (no timeout).
Future work: extend this timeout parameter to a global flag, and support
timeouts on all CLI commands.
From go release history (https://golang.org/doc/devel/release.html#go1.11)
and travis ci build history, looks like 1.11.7 and 1.11.8 contains unknown
bugs that breaks build. To avoid this, fix go version to 1.11.6 for now.
* Added support for --plugin parameter in Fission CLI
This fixes the issue that renaming fission to fission-XYZ would cause a fork bomb, due to the CLI recursively calling itself to discover plugins.
As of K8s 1.8, RBAC mode is stable and backed by the rbac.authorization.k8s.io/v1
API. Using v1beta1 API version for RBAC based objects fails helm deployment
of fission on minikube
It should be possible to keep zero pool size when the environment is created so that there are no idle resources for a newdeploy function. Fixes: https://github.com/fission/fission/issues/1104
This removes fluentd in favor of using fluentbit, which is lighter (in
memory usage) and seems to be more actively maintained.
Fluentbit's config file format is different from fluentd's. It also
doesn't support the same record modification stuff that fluentd
supports, so we have to change the influxdb query slightly. This
means that after an upgrade, the new CLI may won't work for querying older
logs. Hopefully, this slight breakage is acceptable; if users
really need older logs they can use the older CLI.
The root cause of the issue was introduced by PR https://github.com/fission/fission/pull/1009/files .
To be short, even the CRD of environment was delete, it still takes time for executor (poolmgr) to destroy env pool. In our cases, the previous test creates an env and delete it when test finished, then the next one creates the same name env, but failed to create pool due to the deploy name conflict. So the executor selects the pod from the first created env pool. Then, executor starts to delete the env pool, and makes the pod state became Termination state. To fix this problem, a unique name of deployment will be returned after this PR to prevent the name conflict.
* Send the error message to user when enabling canary feature fails.
* Fix controller doesn’t reply canary error when promClient tries connect to invalid prometheus server
* Changed Kafka topic name validation so that capital characters are also allowed
* Removing support for \ in Kafka topic name
* Using raw string some specific sequences
Added support for Kafka headers to be passed and retrieved from functions. The headers and supported and work only for Kafka version 0.11.0.0 and higher.
* Refactor specialization process
* Separate readiness and liveness probe to different routes
For newdeploy, readiness probe should check whether a fetcher specializes env container successfully or not. In this commit, fetcher returns the actual state of current specialization status instead of returning 200ok directly.
Archives with multiple files should have all files in the inputs.
Also clean up some inconsistent variable naming -- archive name,
archive file path, and archive input files were all stored in
incorrectly-named variables.
* Remove version from release name since it contains illegal chars for names
* Put version in release name for uniqueness, but remove invalid chars
* Remove prometheus=false yaml
* Optimize router response time by adding update lock
In 0.9.2, the router sends multiple GetServiceForFunction requests to executor
to get the service URL. However, the response time of executor will increase
under high-concurrency situation due to too many requests are waiting for
processing.
To solve the problem, an update lock was added to the router. All of goroutines belongs
to the same function need to grab the update lock before sending the request.
Only the first goroutine which gets the update lock is allowed to send request.
In this way, we reduce the burden of executor and lower the failure rate.
A simple test for Kafka integration which runs locally provided cluster has Kafka and Fission install has Kafka integratiom enabled (mqtrigger-kafka deployment present).
Improved some of warnings/messages shown to the user when using `fission spec` command. The `spec validate` command now shows appropriate warnings instead
This PR introduces extensibility to the Fission CLI. The principle behind the design of this extensibility is taken from the approach git uses: the main binary (fission) calls other binaries (fission-workflows) - which it discovers using simple prefix-rules - based on specific commands (fission workflow <command>).
* Fix CLI failed to set up port-forwarding when multiple controller pods exist in the same namespace
* Check pod healthy state before establishing the connection
Java environment builder with support for Maven builds. Default build comman runs `mvn clean package` and picks up target/*with-dependencies.jar for function.
This changes image pull policy from Always to IfNotPresent. The previous
policy forbid customer to use the exact image existing on K8S Node.
And it should be OK to use fixed policy here. Customer need not set policy by
their own.
The Round Tripper parameters of timeout, keep alive time and Max retry
times is configured in router system environment.
And they are set to Round Tripper when router service initializing.
This setup new nested structure `tsRoundTripperParams` to transfer them.
This line warns the user that dependent environment doesn’t exist, and presents the command line
for creating an environment.
When the variable `envNamespace` is specified, the `envns` option should be available as well.
* Python Environment: add gevent based WSGI server framework
This supply gevent based WSGI server framework to Python Environment, to
allow customer to run their functions under multi-threads.
* classify the flask based application
This set up the flask based application as individual class, to make
sure the consistent and integrity.
* Add instruction of WSGI server selection applied in Python Environment
* Python Environment starting logger: provide framework name
For certain environments, the archive should not be extracted and kept as it is (For ex. for Java the jar file should not be extracted). This change enables an environment level flag to control this behaviour.
For archives bigger than 256K, the Storage service was called from the client side, this needed few environment variables to be set. This change uses port forwarding to achieve the same and does not need environment variables to be set.
This use constant to instead hard code for ArchiveLiteralSizeLimit. That ensure if the limitation
value is changed in cli, the controller server can follow it. Otherwise, the condition will return
error, and make error HTTP response.
Later, we should delete it in fission-cli, and make it configurable it chart, to work in fission-
servers only.
It is mandatory (from this release onwards) for function to refer to secrets, config-maps and packages in its own namespace to ensure isolation of users sharing the same cluster.
This change runs a pre-upgrade job to verify function references for all functions created prior to this release and fails the upgrade by printing a list of functions that violate this restriction.
Ingress integration to allow the optional creation of ingress for a given route. The ingress controller needs to be set up by the user separately so that ingress path is accessible outside the cluster.
This feature allows creation of fission objects in different namespaces, in addition to retaining the existing behavior of creating fission objects in default namespace if user doesnt provide one.
It also removes cluster admin roles for fission-fetcher and fission-builder Service Accounts and grants them only those privileges that they need.
* Fixes the issue with fn test and adds relevant test cases, fixes#650
* Checking log size for invalid function
* Testing the invalid function logs a few time beforr quitting
* Disabling the test for now, linked to issue #653
The transport in RoundTripper is the default transport and there's just one object shared between different http requests and releasing the idle Connections ended up releasing the idle connections that were established with the executor service address too.
So every time a http request was made to get a service for function, the transport layer ended up having to dial a new connection (that was timing out due to various reasons).
By removing the CloseIdleConnections, we minimize the need for transport to dial a new connection to executor for every request, thereby minimizing the occurrence of dial timeouts.
The router's cache entry for a function might become stale if the pod that had the function specialized gets deleted somehow. In such a case, we'd retry getting a new service for the function from executor and retry forwarding the user request to the newly created service.
Adds a validator, invoked through `fission spec validate` and before `fission spec apply`. The validator checks for duplicate names, dangling references, and unused resources.
Also attempts to fix a race between CLI and builder. Avoids replacing a package while it's building, instead waiting for the build status to change from pending before updating it.
The cli spec dir flag name should be `specdir`, not `specs`, that should match to:
```go
specDirFlag := cli.StringFlag{Name: "specdir", Usage: "Directory to store specs, defaults to ./specs"}
```
in fission/main.go
Currently it cause the specific specs dir not to work.
```
$ fission spec apply --specdir <my spec dir>
Everything up to date.
```
Tests for updates to a function of new deployment executor type. Tests check for changes in the environment, scale, secrets etc. Also checks conversion of function executor type from new deployment to pool manager and vice versa
## Web UI (tracked separately in the fission-ui repo)
## Performance and Scalability ([area-perf](https://github.com/fission/fission/labels/area-perf))
- Autoscaling
- Cold-start optimization -- optimistically choose from pool, save about ~20msec
- Cold-start optimization -- preload funcs in fetcher
- Cold-start optimization -- preload libraries in envs (v2) -- mem vs. speed tradeoff
## Function extensibility ([area-ext](https://github.com/fission/fission/labels/area-ext))
- Env v2: easy addition of dependencies etc.
- Integration with Service Broker
## Multi-area stuff
- Execution strategies: cold-start pool vs create-pod-on-cold-start -- one size doesn't fit all, at least with current tech; abstract over execution strategies according to requirements
An environment contains the language and runtime specific parts of a function. An environment is essentially a container with a webserver and a dynamic loader for the function code.
The following pre-built environments are currently available for use in Fission:
When you create a function, you can specify an executor for a function. An executor controls how function pods are created and what capabilities are available for that executor type.
## Pool-based executor
A pool based executor (Refered to as poolmgr) creates a pool of generic environment pods as soon as you create an environment. The pool size of initial "warm" containers can be configured based on user needs. These warm containers contain a small dynamic loader for loading the function. Resource requirements are specified at environment level and are inherited by specialized function pods.
Once you create a function and invoke it, one of pods from the pool is taken out and "specialized" and used for execution. This pod is used for subseqnent requests for that function. If there are no more requests for a certain idle duration, then this pod is cleaned up. If a new requests come after the earlier specialized pod was cleaned up, then a new pod is specialised from the pool and used for execution.
Poolmgr executortype is great for functions where lower latency is a requirement. Poolmgr executortype has certain limitations: for example, you can not autoscale them based on demand.
## New-deployment executor
New-Deployment executor (Newdeploy) creates a Kubernetes Deployment along with a Service and HorizontalPodAutoscaler for function execution. This enables autoscaling of function pods and load balancing the requests between pods. In future additional capabilities will be added for newdeploy executortype such as support for volume etc. In the new-deploy executor, resource requirements can be specified at the function level. These requirements override those specified in the environment.
Newdeploy executortype can be used for requests with no particular low-latency requirements, such as those invoked asynchronously, minscale can be set to zero. In this case the Kubernetes deployment and other objects will be created on first invocation of the function. Subsequent requests can be served by the same deployment. If there are no requests for certain duration then the idle objects are cleaned up. This mechanism ensures resource consumption only on demand and is a good fit for asynchronous requests.
For requests where latency requirements are stringent, a minscale greater than zero can be set. This essentially keeps a minscale number of pods ready when you create a function. When the function is invoked, there is no delay since the pod is already created. Also minscale ensures that the pods are not cleaned up even if the function is idle. This is great for functions where lower latency is more important than saving resource consumption when functions are idle.
### The latency vs. idle-cost tradeoff
The executors allow you as a user to decide between latency and a small idle cost tradeoff. Depending on the need you can choose one of the combinations which is optimal for your use case. In future, a more intelligent dispatch mechanism will enable more complex combinations of executors.
| Executor Type | Min Scale| Latency | Idle cost |
|:---------|:---------:|:---------:|:---------|
|Newdeploy|0|High|Very low - pods get cleaned up after idlle time|
|Newdeploy|>0|Low|Medium, Min Scale number of pods are always up|
|Poolmgr|0|Low|Low, pool of pods are always up|
### Autoscaling
The new deployment based executor provides autoscaling for functions based on CPU usage. In future custom metrics will be also supported for scaling the functions. You can set the intial and maximum CPU for a function and target CPU at which autoscaling will be trigerred. Autoscaling is useful for workloads where you expect intermittant spikes in workloads. It also enables optimal usage of resources to execute functions, by using a baseline capacity with minimum scale and ability to burst up to maximum scale based on spikes in demand.
A function is a piece of code that will be invoked based on a [trigger](../trigger). The code follows the Fission interface. In practice, the function is only an entry point for execution and it can be backed by a larger program or module.
A function is registered with Fission through a CLI and associated with a trigger. A function can be created based on a single source file or a source archive or a deployment archive.
It is possible to associate and use Kubernetes secrets and configmaps with a function.
Functions also accept minimum and maximum CPU and memory to be assigned, the behaviour of which varies based on executor types which are discussed in greater detail [here](../executor)
Most real world applications are more than a single file of code and typically have dependencies on libraries etc. Packages in fission solve three distinct problems:
1) Enable a mechanism to store more than one file as a single unit and use them with functions. This is done through a combination of deployment archive builder environment associated with the environment.
2) Provide a mechanism to build from source code and dependencies into a binary based on a build command and store it as an object. User should be able to use this built artifact with a function. This is achieved with a source archive and a builder environment.
3) Decouple the execution logic from the functions and thus enable reuse of same logic for multiple functions. This will enable user to run same logic with different functions having different runtime charateristics and executor types.
When you create a function with a single source file, fission internally creates a package and links it to a function. Creating a package explicitly gives more flexibility in some use cases as explained above.
Triggers are events that can invoke a [function](../function). Fission has three kinds of triggers that can be used to invoke functions.
## Http Trigger
HTTP triggers enable calling functions with HTTP requests. Supported methods are GET, POST, PUT, DELETE, HEAD and by default GET is used. URL pattern follow the gorilla/mux supported patterns.
## Time Trigger
If you want a function to be called at a periodic frequency then the time triggers are perfect for the use case. Time triggers follow cron like specifications and are invoked based on the cron schedule.
Time trigger based invocations are great for running scheduled jobs, periodic cleanup jobs, periodic polling based invocations etc.
## MQ Trigger
Message queue based trigger enables ability to listen on a topic and invoke a function for each message. You can optinally send a response to another topic. By default it is assumed that the messages in queue are in application/json format but you can specify otherwise while creating the trigger. Currently `nats-streaming` and `azure-storage-queue` are supported message queues supported.
MQ triggers are great for integrating various systems in a decoupled and asynchronous manner.
- The fission team is on http://slack.fission.io if you have any questions.
### 0.4.0
- This release is compatible with Kubernetes 1.7 onwards.
- We switched from ThirdPartyResources to CustomResourceDefinitions. ThirdPartyResources are removed in Kubernetes 1.8, so upgrade with caution, using the upgrade guide below.
- Upgrade guides:
- [Upgrade guide from 0.3.0](../upgrade/upgrade-from-v0.3)
- To upgrade from 0.2.1, please upgrade to 0.3.0 first, following the upgrade guide in the 0.3.0 release.
### 0.3.0
Note: This release is incompatible with Kubernetes 1.8 (Because it uses ThirdPartyResources; see #314)
This release introduces:
- Build pipeline. Currently, only the Python environment supports this.
- Workflow engine support (compatible with fission-workflows 0.1.1)
### v0.2.1
Lots of big changes in this release!
- Most importantly, the API has changed a lot. We switched to Kubernetes
ThirdPartyResources, and improved various pieces of the API to support
new environments.
- The old API was too different from widely used Kubernetes patterns,
and so we decided to fully break compatibility for this release. We're still in
alpha, so you should expect the occasional API breakage; we'll be
better at preserving compatibility once we reach beta.
- The CLI is still compatible. Environments are also still compatible --
environment images that worked before continue to work.
- We're creating an upgrade tool to help migrate; if you're upgrading
v0.1.0 and can't do a fresh install, wait for the upgrade tool.
- We now use Helm for installation instead of a set of YAML files.
- The Fission "controller" is now stateless. Fission's etcd deployment
is removed, since Fission stores state in ThirdPartyResources. Large
function files are stored in a new function storage service, which
uses a persistent volume.
- And, we've started a new docs site; for now it's just the installation
and upgrade guides, but we'll be writing more docs soon.
You can skip the --server argument if you have the environment
variable `$FISSION_URL` set to point at a v0.3 Fission server.
This will create a JSON file with all your fission state in the
current directory.
### Upgrade to Fission 0.4.0
Upgrade fission with a command similar to this:
```
helm upgrade fission-all --namespace fission
```
### Upgrade Kubernetes cluster version
Since CustomResource is only supported on Kubernetes v1.7+ and higher, please make sure
that you upgrade to the right version that supports CustomResource.
### Remove all TPR definition (for Kubernetes 1.7.x)
** NOTICE **: This step will remove TPR definition from your kubernetes cluster. Please make sure that you dump all TPRs at the second step!
Though Kubernetes will migrate TPRs to CRDs automatically when TPR definition is deleted if the same name CRD exists. We still need to make sure that there is no resource gets lost during the migration. Also, since we changed the capitalization of some CRDs to CamelCase (e.g. Httptrigger -> HTTPTrigger), we need to recreate those resources by ourselves.
```
fission tpr2crd delete
```
### Restore your Fission state into Fission 0.4.0
```
fission tpr2crd restore --file state.json
```
This commands needs `$FISSION_URL` set to point to new fission installation.
It uses the file created in the first step. It doesn't modify state.json.
(Note that you can run this restore on any cluster; it doesn't have the be the same kubernetes
cluster as your old install.)
### Verify
Let's check the migration result, first run following command to check CRD established state.
```
kubectl get crd -o 'custom-columns=NAME:{.metadata.name},ESTABLISHED:{.status.conditions[?(@.type=="Established")].status}'
```
The output should be like this
```
NAME ESTABLISHED
environments.fission.io True
functions.fission.io True
httptriggers.fission.io True
kuberneteswatchtriggers.fission.io True
messagequeuetriggers.fission.io True
packages.fission.io True
timetriggers.fission.io True
```
And check that CRD resources you expect are there.
This is the very first step for fission to integrate with [Istio](https://istio.io/). For those interested in trying to integrate fission with istio, following is the set up tutorial.
## Test Environment
* Google Kubernetes Engine: 1.9.2-gke.1
## Set Up
### Create Kubernetes v1.9+ cluster
Enable both RBAC & initializer features on kubernetes cluster.
``` bash
$ export ZONE=<zone name>
$ gcloud container clusters create istio-demo-1 \
--machine-type=n1-standard-2 \
--num-nodes=1 \
--no-enable-legacy-authorization \
--zone=$ZONE \
--cluster-version=1.9.2-gke.1
```
### Grant cluster admin permissions
Grant admin permission for `system:serviceaccount:kube-system:default` and current user.
For Istio 0.5.1 you can follow the installation tutorial below. Also, you can follow the latest installation guides on Istio official site: [Quick Start](https://istio.io/docs/setup/kubernetes/quick-start.html) and [Sidecar Injection](https://istio.io/docs/setup/kubernetes/sidecar-injection.html).
You can create an environment on your cluster from an image for that language. Optionally, you can specify CPU and memory resource limits. You can also specify the number of initially pre-warmed pods, which is called the poolsize.
In case of pool based executor, the resources specified for environment are used for function pod as well. In case of new deployment executor, you can override the resources when you create a function.
### Using a builder
When you create an environment, you can specify a builder image and builder command which will be used for building from source code. You can override the build command when creating a function. For more details on builder and packages you should check out examples in [Functions](../functions) and [packages](../package)
Let's create a function to demonstrate the autoscaling behaviour in Fission. We create a simple function which outputs "Hello World" in using NodeJS. We have kept the CPU request and limit purposefully low to simulate the load and also kept the target CPU percent to 50%.
While the load is being generated, we will watch the HorizontalPodAutoscaler and how it scales over period of time. As you can notice, the number of pods is scaled from 1 to 3 after the load rises from 8 - 103%. After the load generator stops, it takes a few iterations to scale down from 3 to 1 pod.
```
$ k -n fission-function get hpa -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
You can look at the source code associated with given function:
```
$ fission fn get --name hello
module.exports = async function(context) {
return {
status: 200,
body: "Hello, world!\n"
};
}
```
Let's say you want to update the function to output "Hello Fission" instead of "Hello world", you can update the source file and update the source code for function:
Most real world functions will require more than one source files. It is also easier to simply provide source files and let Fission take care of building from source files. Fission provides first class support for building from source as well as using compiled artifacts to create functions.
You can attach the source/deployment packages to a function or explicitly create packages and use them across functions. Check documentation for [package](../package) for more information.
#### Building function from source
Let's take a simple python function which has dependency on a python pyyaml module. We can specify the dependencies in requirements.txt and a simple command to build from source. The tree structure of directory looks like:
Running setup.py install for pyyaml: finished with status 'done'
Successfully installed pyyaml-3.12
==================
2018/02/16 11:44:24 elapsed time in build request = 3.460498847s
```
Once the build has succeeded, you can hit the function URL to test the function:
```
$curl http://$FISSION_ROUTER/hellopy
a: 1
b: {c: 3, d: 4}
```
#### Using compiled artifacts with Fission
In some cases you have a pre-built deployment package which you need to deploy to Fission. For this example let's use a simple python file as a deployment package but in practice it can be any other compiled package.
We will use a simple python file in a directory and turn it into a deployment package:
```
$ cat testDir/hello.py
def main():
return "Hello, world!"
$zip -jr demo-deploy-pkg.zip testDir/
```
Let's use the deployment package to create a function and route and then test it.
Let's take a simple python function which has dependency on a python pyyaml module. We can specify the dependencies in requirements.txt and a simple command to build from source. The tree structure of directory and contents of the file looks like:
Since we are working with source package, we provided the build command. Once you create the package, the build process will start and you can check the build logs by getting information of the package:
Running setup.py install for pyyaml: finished with status 'done'
Successfully installed pyyaml-3.12
```
Using the package above you can create the function. Since package already is associated with a source package, environment and build command, these will be ignored when creating a function. Only addition thing you will need to provide is the entrypoint. Assuming you hace created the route, the function should be reachable with successful output:
First, it starts with `InternalFuncShowoff` by running `noop`, which is an *internal function* in the workflow engine.
Internal functions are run inside of the workflow engine, which makes them run much faster at the cost of expressiveness and scalability.
So typically, light-weight functions, such as logic or control flow operations, are good candidates to be used as internal functions.
Besides, a minimal set of predefined internal functions, you can define internal function - there is nothing special about them.
After `InternalFuncShowff` completes, the `GenerateFortune` task can start as its `requires` has been fulfilled.
It runs the `fortune` Fission function, which outputs a random piece of wisdom.
After `GenerateFortune` completes, the `WhaleWithFortune` task can start.
This task uses a javascript expression in its `inputs` to reference the output of the `GenerateFortune` task.
In the inputs of a task you can reference anything in the workflow, such as outputs, inputs, and task definitions, or just provide a constant value.
The workflow engine invokes the `whalesay` fission function with as input the piece of wisdom, which outputs the ASCI whale that wraps the phrase.
Finally, with all tasks completed, the workflow engine uses the top-level `output` field to fetch the output of the `WhaleWithFortune` and return it to the user.
As the workflow engine adheres to the Fission function specification, a Fission workflow is just another Fission Function.
This means that you could use this workflow as a function in the `run` in other workflows.
### What's next?
To learn more about the Fission Workflows system and its advanced concepts, see the [documentation on Github](https://github.com/fission/fission-workflows/tree/master/Docs).
Or, check out the [examples](https://github.com/fission/fission-workflows/tree/0.2.0/examples) for more example workflows.
If something went wrong, we'd love to help -- please [drop by the slack channel](http://slack.fission.io) and ask for help.
- [Visit the documentation](https://learn.netlify.com/en/)
## Download old versions (prior to 2.0.0)
If you need old version for compatibility purpose, either download [theme source code from releases](https://github.com/matcornic/hugo-theme-learn/releases) or use the right git tag. For example, with `1.1.0`
- Direct download way: https://github.com/matcornic/hugo-theme-learn/archive/1.1.0.zip
- Git way:
```shell
cd themes/hugo-theme-learn
git checkout tags/1.1.0
```
For both solutions, the documentation is available at https://github.com/matcornic/hugo-theme-learn/releases/download/1.1.0/hugo-learn-doc-1.1.0.zip
## Credits
Many thanks to [@vjeantet](https://github.com/vjeantet/) for the fork [docdock](https://github.com/vjeantet/hugo-theme-docdock). The v2 of this theme is mainly based on his work !
[Hugo-theme-learn](http://github.com/matcornic/hugo-theme-learn) is a theme for [Hugo](https://gohugo.io/), a fast and modern static website engine written in Go. Where Hugo is often used for blogs, this multilingual-ready theme is **fully designed for documentation**.
This theme is a partial porting of the [Learn theme](http://learn.getgrav.org/) of [Grav](https://getgrav.org/), a modern flat-file CMS written in PHP.
{{% notice tip %}}Learn theme works with a _page tree structure_ to organize content : All contents are pages, which belong to other pages. [read more about this]({{%relref "cont/pages/_index.md"%}})
Feel free to update this content, just click the **Edit this page** link displayed on top right of each page, and pullrequest it
{{% notice info %}}
Your modification will be deployed automatically when merged.
{{% /notice %}}
## Documentation website
This current documentation has been statically generated with Hugo with a simple command : `hugo -t hugo-theme-learn` -- source code is [available here at GitHub](https://github.com/matcornic/hugo-theme-learn)
{{% notice note %}}
Automatically published and hosted thanks to [Netlify](https://www.netlify.com/). Read more about [Automated HUGO deployments with Netlify](https://www.netlify.com/blog/2015/07/30/hosting-hugo-on-netlifyinsanely-fast-deploys/)
[Hugo-theme-learn](http://github.com/matcornic/hugo-theme-learn) est un thème pour [Hugo](https://gohugo.io/), un générateur de site statique, rapide et modern, écrit en Go. Tandis que Hugo est souvent utilisé pour des blogs, ce thème multi-langue est **entièrement conçu pour la documentation**.
Ce thème est un portage partiel du [thème Learn](http://learn.getgrav.org/) de [Grav](https://getgrav.org/), un CMS modern écrit en PHP.
{{% notice tip %}}Le thème Learn fonctionne grâce à la structure de page aborescentes pour organiser le contenu: tous les contenus sont des pages qui appartiennent à d'autres pages. [Plus d'infos]({{%relref "cont/pages/_index.md"%}})
N'hésitez pas à mettre à jour ce contenu en cliquant sur le lien **Modifier cette page** en haut de chaque page, et créer la Pull Request associée.
{{% notice info %}}
Votre modification sera déployée automatiquement quand elle sera mergée.
{{% /notice %}}
## Site de documentation
Cette documentation statique a été générée avec Hugo avec une simple commande : `hugo -t hugo-theme-learn` -- le code source est [disponible sur Github](https://github.com/matcornic/hugo-theme-learn)
{{% notice note %}}
Le site est auomatiquement publié et hébergé par [Netlify](https://www.netlify.com/). Plus d'infos sur le [déploiement de site Hugo avec Netlify](https://www.netlify.com/blog/2015/07/30/hosting-hugo-on-netlifyinsanely-fast-deploys/)(En anglais)
On top of [Hugo global configuration](https://gohugo.io/overview/configuration/), **Hugo-theme-learn** lets you define the following parameters in your `config.toml` (here, values are default).
Note that some of these parameters are explained in details in other sections of this documentation.
```toml
[params]
# Prefix URL to edit current page. Will display an "Edit this page" button on top right hand corner of every page.
# Useful to give opportunity to people to create merge request for your doc.
# See the config.toml file from this documentation site to have an example.
editURL=""
# Author of the site, will be used in meta information
author=""
# Description of the site, will be used in meta information
description=""
# Shows a checkmark for visited pages on the menu
showVisitedLinks=false
# Disable search function. It will hide search bar
disableSearch=false
# Javascript and CSS cache are automatically busted when new version of site is generated.
# Set this to true to disable this behavior (some proxies don't handle well this optimization)
disableAssetsBusting=false
# Set this to true to disable copy-to-clipboard button for inline code.
disableInlineCopyToClipBoard=false
# A title for shortcuts in menu is set by default. Set this to true to disable it.
disableShortcutsTitle=false
# When using mulitlingual website, disable the switch language button.
disableLanguageSwitchingButton=false
# Order sections in menu by "weight" or "title". Default to "weight"
ordersectionsby="weight"
# Change default color scheme with a variant one. Can be "red", "blue", "green".
themeVariant=""
```
## Activate search
If not already present, add the follow lines in the same `config.toml` file.
```toml
[outputs]
home=["HTML","RSS","JSON"]
```
Learn theme uses the last improvement available in hugo version 20+ to generate a json index file ready to be consumed by lunr.js javascript search engine.
> Hugo generate lunrjs index.json at the root of public folder.
> When you build the site with hugo server, hugo generates it internally and of course it don’t show up in the filesystem
En plus de la [configuration globale d'Hugo](https://gohugo.io/overview/configuration/), **Hugo-theme-learn** vous permet de définir les paramètres suivant dans votre fichier `config.toml` (ci-dessous sont affichées les valeurs par défaut).
Notez que certains de ces paramètres sont expliqués en détails dans d'autres sections de cette documentation.
```toml
[params]
# L'URL préfixe pour éditer la page courante. Ce paramètre affichera un bouton "Modifier cette page" on haut de de chacune des pages.
# Pratique pour donner les possibilité à vos utilisateurs de créer une merge request pour votre doc.
# Allez voir le fichier config.toml de cette documentation pour avoir un exemple.
editURL=""
# Autheur du site, est utilisé dans les informations meta
author=""
# Description du site, est utilisé dans les informations meta
description=""
# Affiche une icône lorsque la page a été visitée
showVisitedLinks=false
# Désactive la fonction de recherche. Une valeur à true cache la barre de recherche.
disableSearch=false
# Par défaut, le cache Javascript et CSS est automatiquement vidé lorsqu'une nouvelle version du site est générée.
# Utilisez ce paramètre lorsque vous voulez désactiver ce comportement (c'est parfois incompatible avec certains proxys)
disableAssetsBusting=false
# Utilisez ce paramètre pour désactiver le bouton copy-to-clipboard pour le code formatté sur une ligne.
disableInlineCopyToClipBoard=false
# Un titre est défini par défaut lorsque vous utilisez un raccourci dans le menu. Utilisez ce paramètre pour le cacher.
disableShortcutsTitle=false
# Quand vous utilisez un site multi-langue, utilisez ce paramètre pour désactiver le bouton de changement de langue.
disableLanguageSwitchingButton=false
# Ordonne les sections dans menu par poids ("weight") ou titre ("title"). Défaut à "weight"
ordersectionsby="weight"
# Utilisez ce paramètre pour modifier le schéma de couleur du site. Les valeurs par défaut sont "red", "blue", "green".
themeVariant=""
```
## Activer la recherche {#activer-recherche}
Si ce n'est pas déjà présent, ajoutez les lignes suivantes dans le fichier `config.toml`.
```toml
[outputs]
home=["HTML","RSS","JSON"]
```
Le thème *Learn* utilise les dernières amélioraions d'Hugo pour générer un fichier d'index JSON, prêt à être consommé par le moteur de recherche lunr.js.
> Hugo génère lunrjs index.json à la racine du dossier `public`.
> Quand vous générez le site avec `hugo server`, Hugo génère le fichier en mémoire, il n'est donc pas disponible sur le disque.
The following steps are here to help you initialize your new website. If you don't know Hugo at all, we strongly suggest you to train by following this [great documentation for beginners](https://gohugo.io/overview/quickstart/).
## Create your project
Hugo provides a `new` command to create a new website.
```
hugo new site <new_project>
```
## Install the theme
Install the **Hugo-theme-learn** theme by following [this documentation](https://gohugo.io/themes/installing/)
The theme's repository is: https://github.com/matcornic/hugo-theme-learn.git
Alternatively, you can [download the theme as .zip](https://github.com/matcornic/hugo-theme-learn/archive/master.zip) file and extract it in the themes directory
## Basic configuration
When building the website, you can set a theme by using `--theme` option. We suggest you to edit your configuration file and set the theme by default. By the way, add requirements for search functionnality to be enabled.
```toml
# Change the default theme to be use when building the site with Hugo
theme="hugo-theme-learn"
# For search functionnality
[outputs]
home=["HTML","RSS","JSON"]
```
## Create your first chapter page
Chapters are pages containg other child pages. It has a special layout style and usually just contains a _chapter name_, the _title_ and a _brief abstract_ of the section.
```
### Chapter 1
# Basics
Discover what this Hugo theme is all about and the core-concepts behind it.
**Hugo-theme-learn** provides archetypes to create skeletons for your website. Begin by creating your first chapter page with the following command
```
hugo new --kind chapter basics/_index.md
```
By opening the given file, you should see the property `chapter=true` on top, meaning this page is a _chapter_.
By default all chapters and pages are created as draft. If you want to render these pages, remove the property `draft: true` from the metadata.
## Create your first content pages
Then, create content pages inside the previous chapter. Here are two ways to create content in the chapter :
```
hugo new basics/first-content.md
hugo new basics/second-content/_index.md
```
Feel free to edit thoses files by adding some sample content and replacing `title` value in the beginning of the files.
## Launching the website locally
Launch the following command:
```
hugo serve
```
Go to `http://localhost:1313`
You should notice three things:
1. You have a left **Basics** menu, containing two submenus with names equals to `title` properties in previously created files.
2. The home page explains you to how to customize it. Follow the instructions.
3. With `hugo serve` command, the page refresh as soon as you save a file. Neat !
## Build the website
When your site is ready to deploy, launch the following command:
```
hugo
```
A `public` folder has been generated, containing all statics content and assets for your website. It can now be deployed on any web server !
{{% notice note %}}
This website can be automatically published and hosted with [Netlify](https://www.netlify.com/) (Read more about [Automated HUGO deployments with Netlify](https://www.netlify.com/blog/2015/07/30/hosting-hugo-on-netlifyinsanely-fast-deploys/)). Alternatively, you can use [Github pages](https://gohugo.io/hosting-and-deployment/hosting-on-github/)
Les étapes suivantes sont là pour vous aider à initialiser votre site. Si vous ne connaissez pas du tout Hugo, il est fortement conseillé de vous entrainer en suivant ce [super tuto pour débutants](https://gohugo.io/overview/quickstart/).
## Créer votre projet
Hugo fournit une commande `new` pour créer un nouveau site.
```
hugo new site <new_project>
```
## Installer le thème
Installer le thème **Hugo-theme-learn** en suivant [cette documentation](https://gohugo.io/themes/installing/)
Le repo du thème est : https://github.com/matcornic/hugo-theme-learn.git
Sinon, vous pouvez [télécharger le thème sous forme d'un fichier .zip](https://github.com/matcornic/hugo-theme-learn/archive/master.zip) et extrayez le dans votre dossier de thèmes.
## Configuration simple
Lorsque vous générez votre site, vous pouvez définir un thème en utilisant l'option `--theme`. Il est conseillé de modifier votre fichier de configuration `config.toml` and définir votre thème par défaut. En passant, ajoutez les prérequis à l'utilisation de la fonctionnalité de recherche.
```toml
# Modifiez le thème pour qu'il soit utilisé par défaut à chaque génération de site.
theme="hugo-theme-learn"
# Pour la fonctionnalité de recherche
[outputs]
home=["HTML","RSS","JSON"]
```
## Créer votre première page chapitre
Les *chapitres* sont des pages contenant d'autre pages filles. Elles ont un affichage spécial et contiennent habituellement juste un _nom_ de chapitre, le _titre_ et un _résumé_ de la section.
```
### Chapitre 1
# Démarrage
Découvrez comment utiliser ce thème Hugo et apprenez en les concepts
**Hugo-theme-learn** fournit des archétypes pour créer des squelettes pour votre site. Commencez par créer votre premier chapitre avec la commande suivante:
```
hugo new --kind chapter basics/_index.md
```
En ouvrant le fichier généré, vous devriez voir la propriété `chapter=true` en haut, paramètre quit définit que le page est un _chapitre_.
## Créer votre première page
Puis, créez votre premier page dans le chapitre précédent. Pour ce faire, il existe deux possibilités :
```
hugo new basics/first-content.md
hugo new basics/second-content/_index.md
```
N'hésitez pas à éditer ces fichiers en ajoutant des exemple de contenu et en remplaçant le paramètre `title` au début du fichier.
## Lancer le site localement
Lancez la commande suivante :
```
hugo serve
```
Se rendre sur `http://localhost:1313`
Vous devriez voir trois choses:
1. Vous avez un menu **Basics** à gauche, qui contient deux sous-menu avec des noms égal au paramètre `title` des fichiers précédemment générés.
2. La page d'accueil vous explique comment la modifier. Suivez les instructions.
3. Avec la commande `hugo serve`, la page se rafraichit automatiquement à chaque fois que vous sauvegardez. Super !
## Générez le site
Quand votre site est prêt à être déployé, lancez la commande suivante:
```
hugo
```
Un dossier `public` a été généré. Il contient tout le contenu statique et les ressources nécessaires pour votre site. Votre site peut maintenant être déployé en utilisant n'importe quel serveur !
{{% notice note %}}
Ce site peut être automatiquement publié et hébergé avec [Netlify](https://www.netlify.com/) ([Plus d'infos](https://www.netlify.com/blog/2015/07/30/hosting-hugo-on-netlifyinsanely-fast-deploys/)). Sinon, vous pouvez utiliser les [Github pages](https://gohugo.io/hosting-and-deployment/hosting-on-github/)
Thanks to the simplicity of Hugo, this page is as empty as this theme needs requirements.
Just download latest version of [Hugo binary (> 0.25)](https://gohugo.io/getting-started/installing/) for your OS (Windows, Linux, Mac) : it's that simple.
Grâce à la simplicité d'Hugo, cette page est vide car il n'y a quasi pas de prérequis pour utiliser le thème.
Téléchargez la dernière version du [binaire Hugo (> 0.25)](https://gohugo.io/getting-started/installing/) pour votre Système d'exploitation (Windows, Linux, Mac) : et c'est tout !
**Hugo-theme-learn** has been built to be as configurable as possible by defining multiple [partials](https://gohugo.io/templates/partials/)
In `themes/hugo-theme-learn/layouts/partials/`, you will find all the partials defined for this theme. If you need to overwrite something, don't change the code directly. Instead [follow this page](https://gohugo.io/themes/customizing/). You'd create a new partial in the `layouts/partials` folder of your local project. This partial will have the priority.
This theme defines the following partials :
- *header*: the header of the content page (contains the breadcrumbs). _Not meant to be overwritten_
- *custom-header*: custom headers in page. Meant to be overwritten when adding CSS imports. Don't forget to include `style` HTML tag directive in your file
- *footer*: the footer of the content page (contains the arrows). _Not meant to be overwritten_
- *custom-footer*: custom footer in page. Meant to be overwritten when adding Javacript. Don't forget to include `javascript` HTML tag directive in your file
- *favicon*: the favicon
- *logo*: the logo, on top left hand corner.
- *meta*: HTML meta tags, if you want to change default behavior
- *menu*: left menu. _Not meant to be overwritten_
- *menu-footer*: footer of the the left menu
- *search*: search box
- *toc*: table of contents
## Change the logo
Create a new file in `layouts/partials/` named `logo.html`. Then write any HTML you want.
You could use an `img` HTML tag and reference an image created under the *static* folder, or you could paste a SVG definition !
{{% notice note %}}
The size of the logo will adapt automatically
{{% /notice %}}
## Change the favicon
If your favicon is a png, just drop off your image in your local `static/images/` folder and names it `favicon.png`
If you need to change this default behavior, create a new file in `layouts/partials/` named `favicon.html`. Then write something like this:
**Hugo Learn theme** let you choose between 3 native color scheme variants, but feel free to add one yourself ! Default color scheme is based on [Grav Learn Theme](https://learn.getgrav.org/).
### Red variant
```toml
[params]
# Change default color scheme with a variant one. Can be "red", "blue", "green".
First, create a new CSS file in your local `static/css` folder prefixed by `theme` (e.g. with _mine_ theme `static/css/theme-mine.css`). Copy the following content and modify colors in CSS variables.
```css
:root{
--MAIN-TEXT-color:#323232;/* Color of text by default */
--MAIN-TITLES-TEXT-color:#5e5e5e;/* Color of titles h2-h3-h4-h5 */
--MAIN-LINK-color:#1C90F3;/* Color of links */
--MAIN-LINK-HOVER-color:#167ad0;/* Color of hovered links */
--MAIN-ANCHOR-color:#1C90F3;/* color of anchors on titles */
--MENU-HEADER-BG-color:#1C90F3;/* Background color of menu header */
--MENU-HEADER-BORDER-color:#33a1ff;/*Color of menu header border */
--MENU-SEARCH-BG-color:#167ad0;/* Search field background color (by default borders + icons) */
--MENU-SEARCH-BOX-color:#33a1ff;/* Override search field border color */
--MENU-SEARCH-BOX-ICONS-color:#a1d2fd;/* Override search field icons color */
--MENU-SECTIONS-ACTIVE-BG-color:#20272b;/* Background color of the active section and its childs */
--MENU-SECTIONS-BG-color:#252c31;/* Background color of other sections */
--MENU-SECTIONS-LINK-color:#ccc;/* Color of links in menu */
--MENU-SECTIONS-LINK-HOVER-color:#e6e6e6;/* Color of links in menu, when hovered */
--MENU-SECTION-ACTIVE-CATEGORY-color:#777;/* Color of active category text */
--MENU-SECTION-ACTIVE-CATEGORY-BG-color:#fff;/* Color of background for the active category (only) */
--MENU-VISITED-color:#33a1ff;/* Color of 'page visited' icons in menu */
--MENU-SECTION-HR-color:#20272b;/* Color of <hr> separator in menu */
**Hugo-theme-learn** a été conçu pour être aussi configurable que possible en définissant plusieurs [partials](https://gohugo.io/templates/partials/)
Dans `themes/hugo-theme-learn/layouts/partials/`, vous pourrez trouver tous les *partials* définis pour ce thème. Si vous avez besoin d'écraser quelque chose, ne modifiez pas le code directement. A la place, [suivez cette page](https://gohugo.io/themes/customizing/). Vous créerez alors un nouveau *partial* dans le dossier `layouts/partials` de votre site local. Ce *partial* aura la priorité.
Ce thème définit les *partials* suivant :
- *header*: l'en-tête de la page page (contient le fil d'Ariane). _Pas voué à être écrasé_
- *custom-header*: En-tête personnalisé. Voué à être écrasé quand vous ajoutez des imports CSS. N'oubliez pas d'inclure la balise HTML `style` dans votre fichier
- *footer*: le pied-de-page de la page (contains les flèches). _Pas voué à être écrasé_
- *custom-footer*: Pied-de-page personnalisé. Voué à être écrasé quand vous ajoutez du Javascript. N'oubliez pas d'inclure la balise HTML `javascript` dans votre fichier
- *favicon*: le favicon
- *logo*: le logo, affiché un haut à gauche.
- *meta*: les balises HTML meta, que vous pouvez écraser sans problème.
- *menu*: Le menu à gauche. _Pas voué à être écrasé_
- *menu-footer*: Le pied-de-page du menu
- *search*: le champ de recherche
- *toc*: le sommaire
## Changer le logo
Créez un nouveau fichier dans `layouts/partials/`, nommé `logo.html`. Puis, écrivez le code HTML voulu.
Vous pourriez utiliser une balise HTML `img` et référencer une image créée dans le dossier *static*, voire même y coller un cod SVG !
{{% notice note %}}
La taille du logo va s'adapter automatiquement
{{% /notice %}}
## Changer le favicon
Si votre favicon est un png, déposez votre image dans votre dossier local `static/images/` et nommez le `favicon.png`
Si vous avez besoin de changer ce comportement par défaut, créer un nouveau fichier dans `layouts/partials/` et nommez le `favicon.html`. Puis ajoutez quelque chose comme:
## Changer les couleurs par défaut {#theme-variant}
**Hugo Learn theme** vous permet de choisir nativement entre 3 schéma de couleurs, mais n'hésitez pas à en ajouter d'autres ! Les couleurs par défaut sont celles de [Grav Learn Theme](https://learn.getgrav.org/).
### Variante rouge
```toml
[params]
# Modifier le schéma de couleur par défaut. Peut être "red", "blue", "green".
Premièrement, créez un nouveau fichier CSS dans votre dossier `static/css`, préfixé par `theme` (ex: avec le theme_lemien_ `static/css/theme-lemien.css`). Copiez le contenu suivant et modifiez les couleurs dans les variables CSS.
```css
:root{
--MAIN-TEXT-color:#323232;/* Color of text by default */
--MAIN-TITLES-TEXT-color:#5e5e5e;/* Color of titles h2-h3-h4-h5 */
--MAIN-LINK-color:#1C90F3;/* Color of links */
--MAIN-LINK-HOVER-color:#167ad0;/* Color of hovered links */
--MAIN-ANCHOR-color:#1C90F3;/* color of anchors on titles */
--MENU-HEADER-BG-color:#1C90F3;/* Background color of menu header */
--MENU-HEADER-BORDER-color:#33a1ff;/*Color of menu header border */
--MENU-SEARCH-BG-color:#167ad0;/* Search field background color (by default borders + icons) */
--MENU-SEARCH-BOX-color:#33a1ff;/* Override search field border color */
--MENU-SEARCH-BOX-ICONS-color:#a1d2fd;/* Override search field icons color */
--MENU-SECTIONS-ACTIVE-BG-color:#20272b;/* Background color of the active section and its childs */
--MENU-SECTIONS-BG-color:#252c31;/* Background color of other sections */
--MENU-SECTIONS-LINK-color:#ccc;/* Color of links in menu */
--MENU-SECTIONS-LINK-HOVER-color:#e6e6e6;/* Color of links in menu, when hovered */
--MENU-SECTION-ACTIVE-CATEGORY-color:#777;/* Color of active category text */
--MENU-SECTION-ACTIVE-CATEGORY-BG-color:#fff;/* Color of background for the active category (only) */
--MENU-VISITED-color:#33a1ff;/* Color of 'page visited' icons in menu */
--MENU-SECTION-HR-color:#20272b;/* Color of <hr> separator in menu */
Using the command: `hugo new [relative new content path]`, you can start a content file with the date and title automatically set. While this is a welcome feature, active writers need more : [archetypes](https://gohugo.io/content/archetypes/).
It is pre-configured skeleton pages with default front matter. Please refer to the documentation for types of page to understand the differences.
## Chapter {#archetypes-chapter}
To create a Chapter page, run the following commands
```
hugo new --kind chapter <name>/_index.md
```
It will create a page with predefined Front-Matter:
```markdown
+++
title = "{{ replace .TranslationBaseName "-" " " | title }}"
date = {{ .Date }}
weight = 5
chapter = true
pre = "<b>X. </b>"
+++
### Chapter X
# Some Chapter title
Lorem Ipsum.
```
## Default
To create a default page, run either one of the following commands
```
# Either
hugo new <chapter>/<name>/_index.md
# Or
hugo new <chapter>/<name>.md
```
It will create a page with predefined Front-Matter:
```markdown
+++
title = "{{ replace .TranslationBaseName "-" " " | title }}"
En utilisant la commande: `hugo new [chemin vers nouveau contenu]`, vous pouvez créer un nouveau fichier avec la date et le title automatiquement initialisé. Même si c'est une fonctionnalité intéressante, elle reste limitée pour les auteurs actifs qui ont besoin de mieux : les [archetypes](https://gohugo.io/content/archetypes/).
Les archétypes sont des squelettes de pages préconfigurées avec un Front Matter par défaut. Merci de vous référer à la documentation pour connaitre les différents types de page.
## Chapitre {#archetypes-chapter}
Pour créer un chapitre, lancez les commandes suivantes
```
hugo new --kind chapter <name>/_index.md
```
Cela crééra une page avec le Front Matter suivant:
```markdown
+++
title = "{{ replace .TranslationBaseName "-" " " | title }}"
date = {{ .Date }}
weight = 5
chapter = true
pre = "<b>X. </b>"
+++
### Chapter X
# Some Chapter title
Lorem Ipsum.
```
## Défaut
Pour créer une page classique, lancer l'une des deux commandes suivantes
```
# Soit
hugo new <chapter>/<name>/_index.md
# Ou
hugo new <chapter>/<name>.md
```
Cela crééra une page avec le Front Matter suivant:
```markdown
+++
title = "{{ replace .TranslationBaseName "-" " " | title }}"
**Learn theme** is fully compatible with Hugo multilingual mode.
It provides:
- Translation strings for default values (English and French). Feel free to contribute !
- Automatic menu generation from multilingual content
- In-browser language switching
## Basic configuration
After learning [how Hugo handle multilingual websites](https://gohugo.io/content-management/multilingual), define your languages in your `config.toml` file.
For example with current French and English website.
```toml
# English is the default language
defaultContentLanguage="en"
# Force to have /en/my-page and /fr/my-page routes, even for default language.
defaultContentLanguageInSubdir=true
[Languages]
[Languages.en]
title="Documentation for Hugo Learn Theme"
weight=1
languageName="English"
[Languages.fr]
title="Documentation du thème Hugo Learn"
weight=2
languageName="Français"
```
Then, for each new page, append the *id* of the language to the file.
- Single file `my-page.md` is split in two files:
- in English: `my-page.en.md`
- in French: `my-page.fr.md`
- Single file `_index.md` is split in two files:
- in English: `_index.en.md`
- in French: `_index.fr.md`
{{% notice info %}}
Be aware that only translated pages are displayed in menu. It's not replaced with default language content.
{{% /notice %}}
{{% notice tip %}}
Use [slug](https://gohugo.io/content-management/multilingual/#translate-your-content) Front Matter parameter to translate urls too.
{{% /notice %}}
## Overwrite translation strings
Translations strings are used for common default values used in the theme (*Edit this page* button, *Search placeholder* and so on). Translations are available in french and english but you may use another language or want to override default values.
To override these values, create a new file in your local i18n folder `i18n/<idlanguage>.toml` and inspire yourself from the theme `themes/hugo-theme-learn/i18n/en.toml`
By the way, as these translations could be used by other people, please take the time to propose a translation by [making a PR](https://github.com/matcornic/hugo-theme-learn/pulls) to the theme !
## Disable language switching
Switching the language in the browser is a great feature, but for some reasons you may want to disable it.
Just set `disableLanguageSwitchingButton=true` in your `config.toml`
```toml
[params]
# When using mulitlingual website, disable the switch language button.
**Learn** est complètement compatible avec le mode multi-langue d'Hugo.
Il fournit :
- Des *translation strings* pour les valeurs par défaut utilisées par le thème (Anglais et Français). N'hésitez pas à contribuer !
- Génération automatique du menu avec le contenu multi-langue
- Modification de la langue dans le navigateur
## Configuration simple
Après avoir appris [comment Hugo gère les sites multi-langue](https://gohugo.io/content-management/multilingual), définissez vos langues dans votre fichier `config.toml`.
Par exemple, pour ce site, avec du contenu en français et en anglais.
```toml
# Anglais est la langue par défaut
defaultContentLanguage="en"
# Force d'avoir /en/ma-page et /fr/ma-page routes, même avec la langue par défaut.
defaultContentLanguageInSubdir=true
[Languages]
[Languages.en]
title="Documentation for Hugo Learn Theme"
weight=1
languageName="English"
[Languages.fr]
title="Documentation du thème Hugo Learn"
weight=2
languageName="Français"
```
Puis, pour chaque nouvelle page, ajoutez *l'id* de la langue du fichier.
- Le fichier `my-page.md` est découpé en deux fichiers :
- en anglais : `my-page.en.md`
- en français : `my-page.fr.md`
- Le fichier `_index.md` est découpé en deux fichiers :
- en anglais: `_index.en.md`
- en français: `_index.fr.md`
{{% notice info %}}
Attention, seulement les pages traduites sont affichées dans le menu. Le contenu n'est pas remplacé par les pages de la langue par défaut.
{{% /notice %}}
{{% notice tip %}}
Utilisez le paramètre du Front Matter [slug](https://gohugo.io/content-management/multilingual/#translate-your-content) pour traduire également les URLs.
{{% /notice %}}
## Surcharger les *translation strings*
Les *Translations strings* sont utilisées comme valeurs par défaut dans le thème (Bouton *Modifier la page*, Element de subsitution *Recherche*, etc.). Les traductions sont disponibles en français et en anglais mais vous pouvez utiliser n'importe quelle autre langue et surcharger avec vos propres valeurs.
Pour surcharger ces valeurs, créer un nouveau fichier dans votre dossier i18n local `i18n/<idlanguage>.toml` et inspirez vous du thème `themes/hugo-theme-learn/i18n/en.toml`
D'ailleurs, ces traductions pour servir à tout le monde, donc svp prenez le temps de [proposer une Pull Request](https://github.com/matcornic/hugo-theme-learn/pulls) !
## Désactiver le changement de langue
Vous pouvez changer de langue directement dans le navigateur. C'est une super fonctionnalité, mais vous avez peut-être besoin de la désactiver.
Pour ce faire, ajouter le paramètre `disableLanguageSwitchingButton=true` dans votre `config.toml`
```toml
[params]
# Quand vous utilisez un site en multi-langue, désactive le bouton de changment de langue.
This page is a shameful copy of the great [Grav original page](http://learn.getgrav.org/content/markdown).
Only difference is information about image customization ([resizing]({{< relref "#resizing-image" >}}), [add CSS classes]({{< relref "#add-css-classes" >}})...)
{{% /notice%}}
Let's face it: Writing content for the Web is tiresome. WYSIWYG editors help alleviate this task, but they generally result in horrible code, or worse yet, ugly web pages.
**Markdown** is a better way to write **HTML**, without all the complexities and ugliness that usually accompanies it.
Some of the key benefits are:
1. Markdown is simple to learn, with minimal extra characters so it's also quicker to write content.
2. Less chance of errors when writing in markdown.
3. Produces valid XHTML output.
4. Keeps the content and the visual display separate, so you cannot mess up the look of your site.
5. Write in any text editor or Markdown application you like.
6. Markdown is a joy to use!
John Gruber, the author of Markdown, puts it like this:
> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.
> -- <cite>John Gruber</cite>
Grav ships with built-in support for [Markdown](http://daringfireball.net/projects/markdown/) and [Markdown Extra](https://michelf.ca/projects/php-markdown/extra/). You must enable **Markdown Extra** in your `system.yaml` configuration file
Without further delay, let us go over the main elements of Markdown and what the resulting HTML looks like:
{{% notice info %}}
<i class="fa fa-bookmark"></i> Bookmark this page for easy future reference!
{{% /notice %}}
## Headings
Headings from `h1` through `h6` are constructed with a `#` for each level:
```markdown
# h1 Heading
## h2 Heading
### h3 Heading
#### h4 Heading
##### h5 Heading
###### h6 Heading
```
Renders to:
# h1 Heading
## h2 Heading
### h3 Heading
#### h4 Heading
##### h5 Heading
###### h6 Heading
HTML:
```html
<h1>h1 Heading</h1>
<h2>h2 Heading</h2>
<h3>h3 Heading</h3>
<h4>h4 Heading</h4>
<h5>h5 Heading</h5>
<h6>h6 Heading</h6>
```
## Comments
Comments should be HTML compatible
```html
<!--
This is a comment
-->
```
Comment below should **NOT** be seen:
<!--
This is a comment
-->
## Horizontal Rules
The HTML `<hr>` element is for creating a "thematic break" between paragraph-level elements. In markdown, you can create a `<hr>` with any of the following:
*`___`: three consecutive underscores
*`---`: three consecutive dashes
*`***`: three consecutive asterisks
renders to:
___
---
***
## Body Copy
Body copy written as normal, plain text will be wrapped with `<p></p>` tags in the rendered HTML.
So this body copy:
```markdown
Lorem ipsum dolor sit amet, graecis denique ei vel, at duo primis mandamus. Et legere ocurreret pri, animal tacimates complectitur ad cum. Cu eum inermis inimicus efficiendi. Labore officiis his ex, soluta officiis concludaturque ei qui, vide sensibus vim ad.
```
renders to this HTML:
```html
<p>Lorem ipsum dolor sit amet, graecis denique ei vel, at duo primis mandamus. Et legere ocurreret pri, animal tacimates complectitur ad cum. Cu eum inermis inimicus efficiendi. Labore officiis his ex, soluta officiis concludaturque ei qui, vide sensibus vim ad.</p>
```
## Emphasis
### Bold
For emphasizing a snippet of text with a heavier font-weight.
The following snippet of text is **rendered as bold text**.
```markdown
**rendered as bold text**
```
renders to:
**rendered as bold text**
and this HTML
```html
<strong>rendered as bold text</strong>
```
### Italics
For emphasizing a snippet of text with italics.
The following snippet of text is _rendered as italicized text_.
```markdown
_rendered as italicized text_
```
renders to:
_rendered as italicized text_
and this HTML:
```html
<em>rendered as italicized text</em>
```
### strikethrough
In GFM (GitHub flavored Markdown) you can do strikethroughs.
```markdown
~~Strike through this text.~~
```
Which renders to:
~~Strike through this text.~~
HTML:
```html
<del>Strike through this text.</del>
```
## Blockquotes
For quoting blocks of content from another source within your document.
Add `>` before any text you want to quote.
```markdown
> **Fusion Drive** combines a hard drive with a flash storage (solid-state drive) and presents it as a single logical volume with the space of both drives combined.
```
Renders to:
> **Fusion Drive** combines a hard drive with a flash storage (solid-state drive) and presents it as a single logical volume with the space of both drives combined.
and this HTML:
```html
<blockquote>
<p><strong>Fusion Drive</strong> combines a hard drive with a flash storage (solid-state drive) and presents it as a single logical volume with the space of both drives combined.</p>
</blockquote>
```
Blockquotes can also be nested:
```markdown
> Donec massa lacus, ultricies a ullamcorper in, fermentum sed augue.
Nunc augue augue, aliquam non hendrerit ac, commodo vel nisi.
>> Sed adipiscing elit vitae augue consectetur a gravida nunc vehicula. Donec auctor
odio non est accumsan facilisis. Aliquam id turpis in dolor tincidunt mollis ac eu diam.
```
Renders to:
> Donec massa lacus, ultricies a ullamcorper in, fermentum sed augue.
Nunc augue augue, aliquam non hendrerit ac, commodo vel nisi.
>> Sed adipiscing elit vitae augue consectetur a gravida nunc vehicula. Donec auctor
odio non est accumsan facilisis. Aliquam id turpis in dolor tincidunt mollis ac eu diam.
## Notices
{{% notice note %}}
The old mechanism for notices overriding the block quote syntax (`>>>`) has been deprecated. Notices are now handled via a dedicated plugin called [Markdown Notices](https://github.com/getgrav/grav-plugin-markdown-notices)
{{% /notice %}}
## Lists
### Unordered
A list of items in which the order of the items does not explicitly matter.
You may use any of the following symbols to denote bullets for each list item:
```markdown
* valid bullet
- valid bullet
+ valid bullet
```
For example
```markdown
+ Lorem ipsum dolor sit amet
+ Consectetur adipiscing elit
+ Integer molestie lorem at massa
+ Facilisis in pretium nisl aliquet
+ Nulla volutpat aliquam velit
- Phasellus iaculis neque
- Purus sodales ultricies
- Vestibulum laoreet porttitor sem
- Ac tristique libero volutpat at
+ Faucibus porta lacus fringilla vel
+ Aenean sit amet erat nunc
+ Eget porttitor lorem
```
Renders to:
+ Lorem ipsum dolor sit amet
+ Consectetur adipiscing elit
+ Integer molestie lorem at massa
+ Facilisis in pretium nisl aliquet
+ Nulla volutpat aliquam velit
- Phasellus iaculis neque
- Purus sodales ultricies
- Vestibulum laoreet porttitor sem
- Ac tristique libero volutpat at
+ Faucibus porta lacus fringilla vel
+ Aenean sit amet erat nunc
+ Eget porttitor lorem
And this HTML
```html
<ul>
<li>Lorem ipsum dolor sit amet</li>
<li>Consectetur adipiscing elit</li>
<li>Integer molestie lorem at massa</li>
<li>Facilisis in pretium nisl aliquet</li>
<li>Nulla volutpat aliquam velit
<ul>
<li>Phasellus iaculis neque</li>
<li>Purus sodales ultricies</li>
<li>Vestibulum laoreet porttitor sem</li>
<li>Ac tristique libero volutpat at</li>
</ul>
</li>
<li>Faucibus porta lacus fringilla vel</li>
<li>Aenean sit amet erat nunc</li>
<li>Eget porttitor lorem</li>
</ul>
```
### Ordered
A list of items in which the order of items does explicitly matter.
```markdown
1. Lorem ipsum dolor sit amet
2. Consectetur adipiscing elit
3. Integer molestie lorem at massa
4. Facilisis in pretium nisl aliquet
5. Nulla volutpat aliquam velit
6. Faucibus porta lacus fringilla vel
7. Aenean sit amet erat nunc
8. Eget porttitor lorem
```
Renders to:
1. Lorem ipsum dolor sit amet
2. Consectetur adipiscing elit
3. Integer molestie lorem at massa
4. Facilisis in pretium nisl aliquet
5. Nulla volutpat aliquam velit
6. Faucibus porta lacus fringilla vel
7. Aenean sit amet erat nunc
8. Eget porttitor lorem
And this HTML:
```html
<ol>
<li>Lorem ipsum dolor sit amet</li>
<li>Consectetur adipiscing elit</li>
<li>Integer molestie lorem at massa</li>
<li>Facilisis in pretium nisl aliquet</li>
<li>Nulla volutpat aliquam velit</li>
<li>Faucibus porta lacus fringilla vel</li>
<li>Aenean sit amet erat nunc</li>
<li>Eget porttitor lorem</li>
</ol>
```
**TIP**: If you just use `1.` for each number, Markdown will automatically number each item. For example:
```markdown
1. Lorem ipsum dolor sit amet
1. Consectetur adipiscing elit
1. Integer molestie lorem at massa
1. Facilisis in pretium nisl aliquet
1. Nulla volutpat aliquam velit
1. Faucibus porta lacus fringilla vel
1. Aenean sit amet erat nunc
1. Eget porttitor lorem
```
Renders to:
1. Lorem ipsum dolor sit amet
2. Consectetur adipiscing elit
3. Integer molestie lorem at massa
4. Facilisis in pretium nisl aliquet
5. Nulla volutpat aliquam velit
6. Faucibus porta lacus fringilla vel
7. Aenean sit amet erat nunc
8. Eget porttitor lorem
## Code
### Inline code
Wrap inline snippets of code with `` ` ``.
```markdown
In this example, `<section></section>` should be wrapped as **code**.
```
Renders to:
In this example, `<section></section>` should be wrapped with **code**.
HTML:
```html
<p>In this example, <code><section></section></code> should be wrapped with <strong>code</strong>.</p>
```
### Indented code
Or indent several lines of code by at least four spaces, as in:
<pre>
// Some comments
line 1 of code
line 2 of code
line 3 of code
</pre>
Renders to:
// Some comments
line 1 of code
line 2 of code
line 3 of code
HTML:
```html
<pre>
<code>
// Some comments
line 1 of code
line 2 of code
line 3 of code
</code>
</pre>
```
### Block code "fences"
Use "fences" ```` ``` ```` to block in multiple lines of code.
<pre>
``` markup
Sample text here...
```
</pre>
```
Sample text here...
```
HTML:
```html
<pre>
<code>Sample text here...</code>
</pre>
```
### Syntax highlighting
GFM, or "GitHub Flavored Markdown" also supports syntax highlighting. To activate it, simply add the file extension of the language you want to use directly after the first code "fence", ` ```js `, and syntax highlighting will automatically be applied in the rendered HTML. For example, to apply syntax highlighting to JavaScript code:
<pre>
```js
grunt.initConfig({
assemble:{
options:{
assets:'docs/assets',
data:'src/data/*.{json,yml}',
helpers:'src/custom-helpers.js',
partials:['src/partials/**/*.{hbs,md}']
},
pages:{
options:{
layout:'default.hbs'
},
files:{
'./':['src/templates/pages/index.hbs']
}
}
}
};
```
</pre>
Renders to:
```js
grunt.initConfig({
assemble:{
options:{
assets:'docs/assets',
data:'src/data/*.{json,yml}',
helpers:'src/custom-helpers.js',
partials:['src/partials/**/*.{hbs,md}']
},
pages:{
options:{
layout:'default.hbs'
},
files:{
'./':['src/templates/pages/index.hbs']
}
}
}
};
```
## Tables
Tables are created by adding pipes as dividers between each cell, and by adding a line of dashes (also separated by bars) beneath the header. Note that the pipes do not need to be vertically aligned.
```markdown
| Option | Description |
| ------ | ----------- |
| data | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext | extension to be used for dest files. |
```
Renders to:
| Option | Description |
| ------ | ----------- |
| data | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext | extension to be used for dest files. |
And this HTML:
```html
<table>
<tr>
<th>Option</th>
<th>Description</th>
</tr>
<tr>
<td>data</td>
<td>path to data files to supply the data that will be passed into templates.</td>
</tr>
<tr>
<td>engine</td>
<td>engine to be used for processing templates. Handlebars is the default.</td>
</tr>
<tr>
<td>ext</td>
<td>extension to be used for dest files.</td>
</tr>
</table>
```
### Right aligned text
Adding a colon on the right side of the dashes below any heading will right align text for that column.
```markdown
| Option | Description |
| ------:| -----------:|
| data | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext | extension to be used for dest files. |
```
| Option | Description |
| ------:| -----------:|
| data | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext | extension to be used for dest files. |
## Links
### Basic link
```markdown
[Assemble](http://assemble.io)
```
Renders to (hover over the link, there is no tooltip):
Cette page est une copie de la [doc de Grav](http://learn.getgrav.org/content/markdown).
La seule différence porte sur la personalisation des images ([taille]({{< relref "#resizing-image" >}}), [ajout de classes CSS]({{< relref "#add-css-classes" >}})...)
Pour des raisons évidentes, cette page n'a pas été traduites en français 😁
{{% /notice%}}
Let's face it: Writing content for the Web is tiresome. WYSIWYG editors help alleviate this task, but they generally result in horrible code, or worse yet, ugly web pages.
**Markdown** is a better way to write **HTML**, without all the complexities and ugliness that usually accompanies it.
Some of the key benefits are:
1. Markdown is simple to learn, with minimal extra characters so it's also quicker to write content.
2. Less chance of errors when writing in markdown.
3. Produces valid XHTML output.
4. Keeps the content and the visual display separate, so you cannot mess up the look of your site.
5. Write in any text editor or Markdown application you like.
6. Markdown is a joy to use!
John Gruber, the author of Markdown, puts it like this:
> The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions. While Markdown’s syntax has been influenced by several existing text-to-HTML filters, the single biggest source of inspiration for Markdown’s syntax is the format of plain text email.
> -- <cite>John Gruber</cite>
Grav ships with built-in support for [Markdown](http://daringfireball.net/projects/markdown/) and [Markdown Extra](https://michelf.ca/projects/php-markdown/extra/). You must enable **Markdown Extra** in your `system.yaml` configuration file
Without further delay, let us go over the main elements of Markdown and what the resulting HTML looks like:
{{% notice info %}}
<i class="fa fa-bookmark"></i> Bookmark this page for easy future reference!
{{% /notice %}}
## Headings
Headings from `h1` through `h6` are constructed with a `#` for each level:
```markdown
# h1 Heading
## h2 Heading
### h3 Heading
#### h4 Heading
##### h5 Heading
###### h6 Heading
```
Renders to:
# h1 Heading
## h2 Heading
### h3 Heading
#### h4 Heading
##### h5 Heading
###### h6 Heading
HTML:
```html
<h1>h1 Heading</h1>
<h2>h2 Heading</h2>
<h3>h3 Heading</h3>
<h4>h4 Heading</h4>
<h5>h5 Heading</h5>
<h6>h6 Heading</h6>
```
## Comments
Comments should be HTML compatible
```html
<!--
This is a comment
-->
```
Comment below should **NOT** be seen:
<!--
This is a comment
-->
## Horizontal Rules
The HTML `<hr>` element is for creating a "thematic break" between paragraph-level elements. In markdown, you can create a `<hr>` with any of the following:
*`___`: three consecutive underscores
*`---`: three consecutive dashes
*`***`: three consecutive asterisks
renders to:
___
---
***
## Body Copy
Body copy written as normal, plain text will be wrapped with `<p></p>` tags in the rendered HTML.
So this body copy:
```markdown
Lorem ipsum dolor sit amet, graecis denique ei vel, at duo primis mandamus. Et legere ocurreret pri, animal tacimates complectitur ad cum. Cu eum inermis inimicus efficiendi. Labore officiis his ex, soluta officiis concludaturque ei qui, vide sensibus vim ad.
```
renders to this HTML:
```html
<p>Lorem ipsum dolor sit amet, graecis denique ei vel, at duo primis mandamus. Et legere ocurreret pri, animal tacimates complectitur ad cum. Cu eum inermis inimicus efficiendi. Labore officiis his ex, soluta officiis concludaturque ei qui, vide sensibus vim ad.</p>
```
## Emphasis
### Bold
For emphasizing a snippet of text with a heavier font-weight.
The following snippet of text is **rendered as bold text**.
```markdown
**rendered as bold text**
```
renders to:
**rendered as bold text**
and this HTML
```html
<strong>rendered as bold text</strong>
```
### Italics
For emphasizing a snippet of text with italics.
The following snippet of text is _rendered as italicized text_.
```markdown
_rendered as italicized text_
```
renders to:
_rendered as italicized text_
and this HTML:
```html
<em>rendered as italicized text</em>
```
### strikethrough
In GFM (GitHub flavored Markdown) you can do strikethroughs.
```markdown
~~Strike through this text.~~
```
Which renders to:
~~Strike through this text.~~
HTML:
```html
<del>Strike through this text.</del>
```
## Blockquotes
For quoting blocks of content from another source within your document.
Add `>` before any text you want to quote.
```markdown
> **Fusion Drive** combines a hard drive with a flash storage (solid-state drive) and presents it as a single logical volume with the space of both drives combined.
```
Renders to:
> **Fusion Drive** combines a hard drive with a flash storage (solid-state drive) and presents it as a single logical volume with the space of both drives combined.
and this HTML:
```html
<blockquote>
<p><strong>Fusion Drive</strong> combines a hard drive with a flash storage (solid-state drive) and presents it as a single logical volume with the space of both drives combined.</p>
</blockquote>
```
Blockquotes can also be nested:
```markdown
> Donec massa lacus, ultricies a ullamcorper in, fermentum sed augue.
Nunc augue augue, aliquam non hendrerit ac, commodo vel nisi.
>> Sed adipiscing elit vitae augue consectetur a gravida nunc vehicula. Donec auctor
odio non est accumsan facilisis. Aliquam id turpis in dolor tincidunt mollis ac eu diam.
```
Renders to:
> Donec massa lacus, ultricies a ullamcorper in, fermentum sed augue.
Nunc augue augue, aliquam non hendrerit ac, commodo vel nisi.
>> Sed adipiscing elit vitae augue consectetur a gravida nunc vehicula. Donec auctor
odio non est accumsan facilisis. Aliquam id turpis in dolor tincidunt mollis ac eu diam.
## Notices
{{% notice note %}}
The old mechanism for notices overriding the block quote syntax (`>>>`) has been deprecated. Notices are now handled via a dedicated plugin called [Markdown Notices](https://github.com/getgrav/grav-plugin-markdown-notices)
{{% /notice %}}
## Lists
### Unordered
A list of items in which the order of the items does not explicitly matter.
You may use any of the following symbols to denote bullets for each list item:
```markdown
* valid bullet
- valid bullet
+ valid bullet
```
For example
```markdown
+ Lorem ipsum dolor sit amet
+ Consectetur adipiscing elit
+ Integer molestie lorem at massa
+ Facilisis in pretium nisl aliquet
+ Nulla volutpat aliquam velit
- Phasellus iaculis neque
- Purus sodales ultricies
- Vestibulum laoreet porttitor sem
- Ac tristique libero volutpat at
+ Faucibus porta lacus fringilla vel
+ Aenean sit amet erat nunc
+ Eget porttitor lorem
```
Renders to:
+ Lorem ipsum dolor sit amet
+ Consectetur adipiscing elit
+ Integer molestie lorem at massa
+ Facilisis in pretium nisl aliquet
+ Nulla volutpat aliquam velit
- Phasellus iaculis neque
- Purus sodales ultricies
- Vestibulum laoreet porttitor sem
- Ac tristique libero volutpat at
+ Faucibus porta lacus fringilla vel
+ Aenean sit amet erat nunc
+ Eget porttitor lorem
And this HTML
```html
<ul>
<li>Lorem ipsum dolor sit amet</li>
<li>Consectetur adipiscing elit</li>
<li>Integer molestie lorem at massa</li>
<li>Facilisis in pretium nisl aliquet</li>
<li>Nulla volutpat aliquam velit
<ul>
<li>Phasellus iaculis neque</li>
<li>Purus sodales ultricies</li>
<li>Vestibulum laoreet porttitor sem</li>
<li>Ac tristique libero volutpat at</li>
</ul>
</li>
<li>Faucibus porta lacus fringilla vel</li>
<li>Aenean sit amet erat nunc</li>
<li>Eget porttitor lorem</li>
</ul>
```
### Ordered
A list of items in which the order of items does explicitly matter.
```markdown
1. Lorem ipsum dolor sit amet
2. Consectetur adipiscing elit
3. Integer molestie lorem at massa
4. Facilisis in pretium nisl aliquet
5. Nulla volutpat aliquam velit
6. Faucibus porta lacus fringilla vel
7. Aenean sit amet erat nunc
8. Eget porttitor lorem
```
Renders to:
1. Lorem ipsum dolor sit amet
2. Consectetur adipiscing elit
3. Integer molestie lorem at massa
4. Facilisis in pretium nisl aliquet
5. Nulla volutpat aliquam velit
6. Faucibus porta lacus fringilla vel
7. Aenean sit amet erat nunc
8. Eget porttitor lorem
And this HTML:
```html
<ol>
<li>Lorem ipsum dolor sit amet</li>
<li>Consectetur adipiscing elit</li>
<li>Integer molestie lorem at massa</li>
<li>Facilisis in pretium nisl aliquet</li>
<li>Nulla volutpat aliquam velit</li>
<li>Faucibus porta lacus fringilla vel</li>
<li>Aenean sit amet erat nunc</li>
<li>Eget porttitor lorem</li>
</ol>
```
**TIP**: If you just use `1.` for each number, Markdown will automatically number each item. For example:
```markdown
1. Lorem ipsum dolor sit amet
1. Consectetur adipiscing elit
1. Integer molestie lorem at massa
1. Facilisis in pretium nisl aliquet
1. Nulla volutpat aliquam velit
1. Faucibus porta lacus fringilla vel
1. Aenean sit amet erat nunc
1. Eget porttitor lorem
```
Renders to:
1. Lorem ipsum dolor sit amet
2. Consectetur adipiscing elit
3. Integer molestie lorem at massa
4. Facilisis in pretium nisl aliquet
5. Nulla volutpat aliquam velit
6. Faucibus porta lacus fringilla vel
7. Aenean sit amet erat nunc
8. Eget porttitor lorem
## Code
### Inline code
Wrap inline snippets of code with `` ` ``.
```markdown
In this example, `<section></section>` should be wrapped as **code**.
```
Renders to:
In this example, `<section></section>` should be wrapped with **code**.
HTML:
```html
<p>In this example, <code><section></section></code> should be wrapped with <strong>code</strong>.</p>
```
### Indented code
Or indent several lines of code by at least four spaces, as in:
<pre>
// Some comments
line 1 of code
line 2 of code
line 3 of code
</pre>
Renders to:
// Some comments
line 1 of code
line 2 of code
line 3 of code
HTML:
```html
<pre>
<code>
// Some comments
line 1 of code
line 2 of code
line 3 of code
</code>
</pre>
```
### Block code "fences"
Use "fences" ```` ``` ```` to block in multiple lines of code.
<pre>
``` markup
Sample text here...
```
</pre>
```
Sample text here...
```
HTML:
```html
<pre>
<code>Sample text here...</code>
</pre>
```
### Syntax highlighting
GFM, or "GitHub Flavored Markdown" also supports syntax highlighting. To activate it, simply add the file extension of the language you want to use directly after the first code "fence", ` ```js `, and syntax highlighting will automatically be applied in the rendered HTML. For example, to apply syntax highlighting to JavaScript code:
<pre>
```js
grunt.initConfig({
assemble:{
options:{
assets:'docs/assets',
data:'src/data/*.{json,yml}',
helpers:'src/custom-helpers.js',
partials:['src/partials/**/*.{hbs,md}']
},
pages:{
options:{
layout:'default.hbs'
},
files:{
'./':['src/templates/pages/index.hbs']
}
}
}
};
```
</pre>
Renders to:
```js
grunt.initConfig({
assemble:{
options:{
assets:'docs/assets',
data:'src/data/*.{json,yml}',
helpers:'src/custom-helpers.js',
partials:['src/partials/**/*.{hbs,md}']
},
pages:{
options:{
layout:'default.hbs'
},
files:{
'./':['src/templates/pages/index.hbs']
}
}
}
};
```
## Tables
Tables are created by adding pipes as dividers between each cell, and by adding a line of dashes (also separated by bars) beneath the header. Note that the pipes do not need to be vertically aligned.
```markdown
| Option | Description |
| ------ | ----------- |
| data | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext | extension to be used for dest files. |
```
Renders to:
| Option | Description |
| ------ | ----------- |
| data | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext | extension to be used for dest files. |
And this HTML:
```html
<table>
<tr>
<th>Option</th>
<th>Description</th>
</tr>
<tr>
<td>data</td>
<td>path to data files to supply the data that will be passed into templates.</td>
</tr>
<tr>
<td>engine</td>
<td>engine to be used for processing templates. Handlebars is the default.</td>
</tr>
<tr>
<td>ext</td>
<td>extension to be used for dest files.</td>
</tr>
</table>
```
### Right aligned text
Adding a colon on the right side of the dashes below any heading will right align text for that column.
```markdown
| Option | Description |
| ------:| -----------:|
| data | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext | extension to be used for dest files. |
```
| Option | Description |
| ------:| -----------:|
| data | path to data files to supply the data that will be passed into templates. |
| engine | engine to be used for processing templates. Handlebars is the default. |
| ext | extension to be used for dest files. |
## Links
### Basic link
```markdown
[Assemble](http://assemble.io)
```
Renders to (hover over the link, there is no tooltip):
name = "<i class='fa fa-bookmark'></i> Hugo Documentation"
identifier = "hugodoc"
url = "https://gohugo.io/"
weight = 20
[[menu.shortcuts]]
name = "<i class='fa fa-bullhorn'></i> Credits"
url = "/credits"
weight = 30
By default, shortcuts are preceded by a title. This title can be disabled by setting `disableShortcutsTitle=true`.
However, if you want to keep the title but change its value, it can be overriden by changing your local i18n translation string configuration.
For example, in your local `i18n/en.toml` file, add the following content
[Shortcuts-Title]
other = "<Your value>"
Read more about [hugo menu](https://gohugo.io/extras/menus/) and [hugo i18n translation strings](https://gohugo.io/content-management/multilingual/#translation-of-strings)
## Configuration for Multilingual mode {#i18n}
When using a multilingual website, you can set different menus for each language. In the `config.toml` file, prefix your menu configuration by `Languages.<language-id>`.
name = "<i class='fa fa-bookmark'></i> Hugo Documentation"
identifier = "hugodoc"
url = "https://gohugo.io/"
weight = 20
[[menu.shortcuts]]
name = "<i class='fa fa-bullhorn'></i> Credits"
url = "/credits"
weight = 30
Par défaut, les raccourcis sont précédés par un titre. Ce titre peut être désactivé en ajouter le paramètre `disableShortcutsTitle=true` dans la section `params` de votre `config.toml`.
Cependant, si vous voulez garder le titre mais changer sa valeur, vous pouvez modifier votre configuration multilangue locale en changeant les *translation string*.
Par exemple, dans votre fichier local `i18n/en.toml`, ajouter le contenu
[Shortcuts-Title]
other = "<Votre valeur>"
Plus d'infos sur [les menus Hugo](https://gohugo.io/extras/menus/) et sur [les translations strings](https://gohugo.io/content-management/multilingual/#translation-of-strings)
## Configuration pour le mode multi-langue {#i18n}
Quand vous utilisez un site multi-langue, vous pouvez avoir des menus différents pour chaque langage. Dans le fichier de configuration `config.toml`, préfixez votre configuration par `Languages.<language-id>`.
name = "<i class='fa fa-bookmark'></i> Documentation Hugo"
identifier = "hugodoc"
url = "https://gohugo.io/"
weight = 20
[[Languages.fr.menu.shortcuts]]
name = "<i class='fa fa-bullhorn'></i> Crédits"
url = "/credits"
weight = 30
Plus d'infos sur [les menus Hugo](https://gohugo.io/extras/menus/) et les [menus multi-langue Hugo](https://gohugo.io/content-management/multilingual/#menus)
In **Hugo**, pages are the core of your site. Once it is configured, pages are definitely the added value to your documentation site.
## Folders
Organize your site like [any other Hugo project](https://gohugo.io/content/organization/). Typically, you will have a *content* folder with all your pages.
`_index.md` is required in each folder, it’s your “folder home page”
{{% /notice %}}
## Types
**Hugo-theme-learn** defines two types of pages. *Default* and *Chapter*. Both can be used at any level of the documentation, the only difference being layout display.
A **Chapter** displays a page meant to be used as introduction for a set of child pages. Commonly, it contains a simple title and a catch line to define content that can be found under it.
You can define any HTML as prefix for the menu. In the example below, it's just a number but that could be an [icon](https://fortawesome.github.io/Font-Awesome/).
The following steps are here to help you initialize your new website. If you don't know Hugo at all, we strongly suggest you to train by following this [great documentation for beginners](https://gohugo.io/overview/quickstart/).
## Create your project
Hugo provides a `new` command to create a new website.
```
hugo new site <new_project>
```
**Hugo-theme-learn** provides [archetypes]({{< relref "cont/archetypes.fr.md" >}}) to help you create this kind of pages.
## Front Matter configuration
Each Hugo page has to define a [Front Matter](https://gohugo.io/content/front-matter/) in *yaml*, *toml* or *json*.
**Hugo-theme-learn** uses the following parameters on top of Hugo ones :
```toml
+++
# Table of content (toc) is enabled by default. Set this parameter to true to disable it.
# Note: Toc is always disabled for chapter pages
disableToc="false"
# If set, this will be used for the page's menu entry (instead of the `title` attribute)
menuTitle=""
# The title of the page in menu will be prefixed by this HTML content
pre=""
# The title of the page in menu will be postfixed by this HTML content
post=""
# Set the page as a chapter, changing the way it's displayed
chapter=false
# Hide a menu entry by setting this to true
hidden=false
# Display name of this page modifier. If set, it will be displayed in the footer.
LastModifierDisplayName=""
# Email of this page modifier. If set with LastModifierDisplayName, it will be displayed in the footer
LastModifierEmail=""
+++
```
### Add icon to a menu entry
In the page frontmatter, add a `pre` param to insert any HTML code before the menu label. The example below uses the Github icon.
```toml
+++
title="Github repo"
pre="<i class='fa fa-github'></i> "
+++
```
### Ordering sibling menu/page entries
Hugo provides a [flexible way](https://gohugo.io/content/ordering/) to handle order for your pages.
The simplest way is to set `weight` parameter to a number.
```toml
+++
title="My page"
weight=5
+++
```
### Using a custom title for menu entries
By default, **Hugo-theme-learn** will use a page's `title` attribute for the menu item (or `linkTitle` if defined).
But a page's title has to be descriptive on its own while the menu is a hierarchy.
We've added the `menuTitle` parameter for that purpose:
For example (for a page named `content/install/linux.md`):
```toml
+++
title="Install on Linux"
menuTitle="Linux"
+++
```
## Homepage
To configure your home page, you basically have three choices:
1. Create an `_index.md` document in `content` folder and fill the file with *Markdown content*
2. Create an `index.html` file in the `static` folder and fill the file with *HTML content*
3. Configure your server to automatically redirect home page to one your documentation page
Dans **Hugo**, les pages sont le coeur de votre site. Une fois configurées, les pages sont la valeur ajoutée de votre site de documentation.
## Dossiers
Organisez votre site comment n'importe quel autre [projet Hugo](https://gohugo.io/content/organization/). Typiquement, vous allez avoir un dossier *content* avec vos pages.
Le fichier `_index.md` est obligatoire dans chaque dossier, c'est en quelques rotes votre page d'accueil pour le dossier.
{{% /notice %}}
## Types
**Hugo-theme-learn** définit deux types de pages. *Défaut* et *Chapitre*. Les deux sont utilisables à n'importe quel niveau du site, la seule différence est dans l'affichage.
Un **Chapitre** affiche une page vouée à être une introduction pour un ensemble de pages filles. Habituellement, il va seulement contenir un titre et un résumé de la section.
Vous pouvez définir n'importe quel contenu HTML comme préfixe de l'entrée du menu. Dans l'exemple ci-dessous, c'est juste un nombre mais vous pourriez utiliser une [icône](https://fortawesome.github.io/Font-Awesome/).
The following steps are here to help you initialize your new website. If you don't know Hugo at all, we strongly suggest you to train by following this [great documentation for beginners](https://gohugo.io/overview/quickstart/).
## Create your project
Hugo provides a `new` command to create a new website.
```
hugo new site <new_project>
```
**Hugo-theme-learn** fournit des [archétypes]({{< relref "cont/archetypes.fr.md" >}}) pour vous aider à créer ce type de pages.
## Configuration des Front Matter
Chaque page Hugo doit définir un [Front Matter](https://gohugo.io/content/front-matter/) dans le format *yaml*, *toml* ou *json*.
**Hugo-theme-learn** utilise les paramètres suivant en plus de ceux définis par Hugo:
```toml
+++
# Le Sommaire (table of content = toc) est activé par défaut. Modifier ce paramètre à true pour le désactiver.
# Note: Le sommaire est toujours désactivé pour les chapitres
disableToc = "false"
# Le titre de la page dans le menu sera préfixé par ce contentu HTML
pre = ""
# Le titre de la page dans le menu sera suffixé par ce contentu HTML
post = ""
# Modifier le type de la page pour changer l'affichage
chapter = false
# Cache la page du menu
hidden = false
# Nom de la personne qui a modifié la page. Quand configuré, sera affiché dans le pied de page.
LastModifierDisplayName = ""
# Email de la personne qui a modifié la page. Quand configuré, sera affiché dans le pied de page.
LastModifierEmail = ""
+++
```
### Ajouter une icône à une entrée du menu
Dans le Front Matter, ajouter un paramètre `pre` pour insérer du code HTML qui s'affichera avant le label du menu. L'exemple ci-dessous utilise l'icône de Github.
```toml
+++
title = "Repo Github"
pre = "<i class='fa fa-github'></i> "
+++
```
### Ordonner les entrées dans le menu
Hugo permet de modifier facilement [l'ordre des menu](https://gohugo.io/content/ordering/).
La manière la plus simple est de configurer le paramètre `weight` avec un nombre.
```toml
+++
title = "Ma page"
weight = 5
+++
```
## Page d'accueil
Pour configurer votre page d'accueil, vous avez trois choix:
1. Créer une page `_index.md` dans le dossier `content` et remplissez le fichier avec du *contenu Markdown*
2. Créer une page `index.html` dans le dossier `static` et remplissez le fichier avec du *contenu HTML*
3. Configurez votre serveur pour automatiquement rediriger la page d'accueil vers l'une de vos pages.
And a special thanks to [@vjeantet](https://github.com/vjeantet) for his work on [docdock](https://github.com/vjeantet/hugo-theme-docdock), a fork of hugo-theme-learn. v2.0.0 of this theme is inspired by his work.
## Packages and libraries
* [mermaid](https://knsv.github.io/mermaid) - generation of diagram and flowchart from text in a similar manner as markdown
* [font awesome](http://fontawesome.io/) - the iconic font and CSS framework
* [jQuery](https://jquery.com) - The Write Less, Do More, JavaScript Library
* [lunr](https://lunrjs.com) - Lunr enables you to provide a great search experience without the need for external, server-side, search services...
* [horsey](https://bevacqua.github.io/horsey/) - Progressive and customizable autocomplete component
* [clipboard.js](https://zenorocha.github.io/clipboard.js) - copy text to clipboard
* [modernizr](https://modernizr.com) - A JavaScript toolkit that allows web developers to use new CSS3 and HTML5 features while maintaining a fine level of control over browsers that don't support
## Tooling
* [Netlify](https://www.netlify.com) - Continuous deployement and hosting of this documentation
Et un grand merci à [@vjeantet](https://github.com/vjeantet) pour son travail sur [docdock](https://github.com/vjeantet/hugo-theme-docdock), un fork de _hugo-theme-learn_. La v2.0.0 du thème est en grande partie inspirée de son travail.
## Packages et librairies
* [mermaid](https://knsv.github.io/mermaid) - géneration de diagrames et graphiques à partir de texte similaire à Markdown
* [font awesome](http://fontawesome.io/) - Le framework de polices iconiques
* [jQuery](https://jquery.com) - La plus connue des librairies Javascript
* [lunr](https://lunrjs.com) - Lunr fournit des fonctions de recherche sans service externe
* [horsey](https://bevacqua.github.io/horsey/) - Autocomplétion de composants (utiliser pour les suggestions de recherche)
* [clipboard.js](https://zenorocha.github.io/clipboard.js) - Copier le texte dans le presse-papier
* [highlight.js](https://highlightjs.org) - Mise en valeur de syntaxes
* [modernizr](https://modernizr.com) - Une boite à outil Javascript qui permet aux développeurs d'utiliser les dernières fonctionnalités de CSS et HTML5, même sur de vieux navigateurs.
## Outils
* [Netlify](https://www.netlify.com) - Déploiement continue et hébergement de cette documentation
Hugo uses Markdown for its simple content format. However, there are a lot of things that Markdown doesn’t support well. You could use pure HTML to expand possibilities.
But this happens to be a bad idea. Everyone uses Markdown because it's pure and simple to read even non-rendered. You should avoid HTML to keep it as simple as possible.
To avoid this limitations, Hugo created [shortcodes](https://gohugo.io/extras/shortcodes/). A shortcode is a simple snippet inside a page.
**Hugo-theme-learn** provides multiple shortcodes on top of existing ones.
Hugo utilise Markdown pour son format simple. Cependant, il y a beaucoup de chose que Markdown ne supporte pas bien. On pourrait utiliser du HTML pur pour améliorer les capacité du Markdown.
Mais c'est probablement une mauvaise idée. Tout le monde utilise le Markdown parce que c'est pur et simple à lire même lorsqu'il est affiché en texte brut. Vous devez éviter le HTML autant que possible pour garder le contenu simple.
Cependant, pour éviter les limitations, Hugo a créé les [shortcodes](https://gohugo.io/extras/shortcodes/). Un shortcode est un bout de code (*snippet*) dans une page.
**Hugo-theme-learn** fournit de multiple shortcodes en plus de ceux existant.
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
