zenorocha / wedocs Goto Github PK
View Code? Open in Web Editor NEWDocumentation for WeDeploy
Home Page: http://wedeploy.com/docs
Documentation for WeDeploy
Home Page: http://wedeploy.com/docs
After the implementation of https://github.com/wedeploy/api-js/issues/79, we have to update the documentation to describe the API.
Hey,
currently we don't mention the docker version necessary for running wedeploy
. We should also be explicit that in macosx
we target docker for mac.
Document valid ids, supported fields.
Hey,
currently in the boilerplate-*
READMEs we're just directing the user to /docs
, but i feel that someone who simply git clone
s the repository might be inclined to stick with README.md
. Should we document the repositories in their READMEs or let that to /docs
? Wdyt?
Thx!
Document how to protect a path using parameters. Here is an example:
{
"data": true,
"path": "/boards",
"parameters": {
"filter": {
"value": {"userId":{"operator":"=","value":"$auth.id"}}
}
}
}
Hey,
when you run a normal docker/etc container and you bind solely to localhost (loopback iface) you can't reach it by touching the bound port. As we rely on such behavior right now, it'd be good that the documentation for these types reflect this
If we follow the documentation here and run:
we link
we get the following error:
Error: Project not found
It looks we have to specify the name of the project, like:
we link --project demo
Docs currently lack information how to protect a collection to be accessed only by authenticated user.
For example, the following code will forbid anonymous requests to boards
collection by checking if the field userId
in the boards
collection matches the Id of currently authenticated user:
[
{
"data": true,
"path": "/boards",
"parameters": {
"filter": {
"value": {"userId":{"operator":"=","value":"$auth.id"}}
}
}
}
]
Currently the hooks inside container.json
are not documented.
We have to document them and describe possible use cases.
When developing an application, the output is often produced from some build process.
This could be a Gulp/Grunt task and the result is usually in a folder called out
or dist
. In this case, index.html
won't be in the main folder, but in dist
or out
.
We have to add to the documentation information about how to specify where the output result is. This is the purpose of WEDEPLOY_WEB_PATH
environment variable. Its value specifies where WeDeploy hosting service will look for the files.
Make it clear the better way to use this approach where:
www.mydomain.com is a CNAME to mydomain.com
ivansj.com is an A to wedeploy IP.
the custom domain there is pointing to mydomain.com
The service is called web.
I tried http://web.mydomain.com
and since I didn't configure web on my domain DNS it is not working. Maybe we need good instructions for this approach.
In the Custom Domain screen in the console, the user won't be able to save his settings if his NS settings haven't be propagated yet.
So the issue bellow was created to show a more descriptive message to the user about the propagation issue:
https://github.com/wedeploy/console/issues/294
So, I think it would be a good idea if the docs page about Custom Domain reinforces it too.
The docs page I'm referring to is the one bellow:
https://wedeploy.com/docs/intro/custom-domains/
Hey, some simple things like allowed origins are set by default but we don't explicitly state how it is. Perhaps it'd be a good idea to document them. As it affects data
, auth
and email
directly i'm not sure what'd be the best way of doing it.
Wdyt?
List all available filter operators from data.
The process of adding users with roles has to be added to the documentation.
Protecting given path with roles have to be added to the documentation. Here is an example:
{
"data": true,
"path": "/",
"auth": {
"scopes": ["admin"]
}
}
We have to add to the docs information about how to deploy an already existing application.
At the moment, when reading the documentation about the hosting service, the developer gets the impression that the recommended (or the only) way of deploying the app is to fork a boilerplate and commit its content to WeDeploy's Git server.
Although this is a valid scenario, in many cases this would be an extra step, which the developers would prefer to avoid. In most of the cases the developer works on his project and at some point he decides to deploy it. The recommended way of forking a boilerplate gives the impression to the developer that he should have two repositories - one where he develops and another one (the forked boilerplate) where he has to put the content which will be deployed.
Obviously this is an incorrect assumption and that's why project.json
and container.json
exist. They are documented here, but there is no relation between them and the documentation of the services, so the developer cannot figure out how to use project.json
and container.json
in his own project.
Apart from adding a relation between these and the documentation of the different services, it would be good to have a separate section in the docs, where we take an existing project and explain how to add to it the different services. From these e can create videos on YouTube and embed them to the docs.
We can document this limitation of cli about project and container ids.
https://github.com/cirocosta/hackaday-wedeploy-feedback/issues/18
Hey,
just noticed that Login
in the landing leads to dashboard.wedeploy.io
. There are certainly others like that elsewhere.
Hey,
one of our users had trouble trying to we link
a service that was not within docker-for-mac shared folders set. That's something that could be evicted through documenting the configuration of docker-for-mac more extensively.
Wdyt?
Thx!
The hosting service provides OOTB some goodies for the developers. These include ETag and gzip compression. The fact that ETag is available would save some work of the developer, because he won't have to add versions to his CSS and JS files to force the browser to reload them when a new version is created.
We need to document which callback url he must add. For example:
auth.myproject.wedeploy.io/oauth/token
Or, for local development:
auth.myproject.wedeploy.me/oauth/token
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.