Factory Behavior

Factory Creation Workflow

The below scheme outlines the workflow and process that Codenvy goes through to create a temporary workspace, and the subsequent project that is loaded into it after a Factory has been selected:

factory_workflow

Once a user clicks on a Factory, the associated git repository will be cloned from the git revision point specified in the URL into a temporary workspace. This workspace will be deleted if the browser tab is closed or if the workspace is idle for a period of time. This workspace will be deleted once no activity will be detected on it. The temporary project is configured by the project type, so user will be able to code, build, test and run directly from this temporary workspace.

The URL that makes up the newly generated workspace can be shared with others. Other people who access the temporary workspace URL will be inserted into the same temporary workspace and will be allowed to pair program, chat, and see the other person’s cursor. Other users that click on the Factory URL will generate a different temporary workspace. The “invite” function in a temporary workspace is grayed out even though the URL may be shared and collaboration is allowed. Today “Invite User” in the share menu is mislabeled and really means, “Manage User Permissions”, which involves a key exchange and granting specialized permissions on named accounts. We’ll eventually rename this functionality and then make “Invite Users” merely a simple email with the embedded temporary workspace URL.

The temporary workspace is just that – temporary. The work will be destroyed if the project is idle. The work can be made persistent and stored in long term storage if the user creates an account with Codenvy. If the user is not registered already, there is a window provided to create an account. If the user is already authenticated and we can detect that through cookies, then they are allowed to copy the project directly into their permanent workspace associated with their account.

Temporary vs. Permanent Workspaces

A temporary workspace is a workspace that has a project, code repository, and some code, build, test, debug services, but structured into a quarantined zone such that work cannot be long-term persisted. A temporary workspace will be destroyed if it is left idle or the browser is closed. In a temporary workspace, there are certain behaviors that must be repeated for each action, such as authenticating to an outside provider, since the system will not persist any of those credentials. A permanent workspace is one that is bound to a user or an organization, and the projects inside of it are persisted. Additionally, the system will persist account information, credentials to outside services, such as SSH keys to GitHub, and allow for public / private project functions.

Temporary workspaces behave similarly for non-authenticated users and for authenticated users. For those individuals that have a registered account, they can then copy the project into their permanent workspace. And for those users that do not have an account, they can execute the authentication process and the project will be copied after authentication is confirmed.

Architecturally, the difference between a temporary and named workspace is whether or not persistence storage (LDAP) is used to store related account information. The temporary workspace has a full user profile, but since that information is kept entirely in-memory, any destruction of the tenant itself causes the wiping of the entire project space. We also place all temporary tenants into an isolated portion of the virtual file system to be able to run batch cleanup and reporting algorithms against those files.

A permanent workspace is one that is bound to a user or an organization, and the projects inside of it are persisted. Additionally, the system will persist account information, credentials to outside services, such as SSH keys to GitHub, and allow for public / private project functions.

Anonymous Users vs. Named Accounts

Anonymous Users

An anonymous user is one where they are accessing the system and no identifiable credentials can be associated with the account. Anonymous users can exist in one of two scenarios:

  • A user without a cookie initiates a Factory operation, placing them into a temporary workspace
  • A user gains access to a public project URL and enters into the product through that URL in read-only mode

The behavior of the system is different for anonymous users vs. named users. With anonymous users, it is possible for administrators to configure which features of the product are available through a set of configuration parameters accessible through configuration files. These anonymous users must either create an account or authenticate (either outside of the product, or within it) in order for these capabilities to be re-activated. Also, anonymous users have all of their traffic routed to an IDE cluster that is quarantined from other IDE clusters that handle named user traffic. This routing and isolation takes place using HAProxy and cloud administration IP that we have authored.

Architecturally, anonymous users have an automatically generated user name, but just not persisted into LDAP. They are in-memory only. Both anonymous and named users have an associated set of permissions, and are members of groups. With anonymous users, their associated groups and permissions are pre-determined and cannot be altered.

Named Accounts

A named user is one that has an associated account and is granted configurable permissions to access protected resources. Named user information is persisted into LDAP.

Factory for Public vs. Private Codenvy Workspaces

Private Codenvy workspaces are available for premium Codenvy accounts. Projects in a private workspace are invisible in a read only mode. Only workspace owner and invited users (having relevant ACL rights) can access private projects.

Factory for Public Codenvy Workspaces

Creating a factory from a public Codenvy workspace is possible for all users who own it or are invited users. The Factory can be used by all users, anonymous or named, and clicking a Factory button it will result in creation of a public temporary workspace that can be shared with others.

A factory for a public Codenvy workspace:

Factory - Public WorkspacePermissions
Can be created by:Codenvy users with relevant permissions for the workspace
Can be used by:A Factory on a public Codenvy workspace can be used by anyone without restriction. Clicking on the Factory URL will create a temporary workspace that is a clone of the originating workspace
Temporary workspace:Public, can be shared
Collaboration sessions:Enabled

Factory for Private Codenvy Workspaces

As specific ACL is applied to a private Codenvy workspace, a Factory is following these specifics. Creation of a Factory is still possible for users who own a private workspace or have been invited to it. The main difference in the workflow is a private Codenvy workspace can have a Factory only created by, and accessed by users who have the appropriate permissions within the workspace. A Factory created from a private Codenvy workspace can only be only consumed by users with the appropriate permissions. Creation of a Factory from a private Codenvy workspace is only possible for an authenticated user.It is not possible to have a shared collaborative session with that Factory. It is essentially a single-user temporary workspace, private and secure.

A Factory for a Private Codenvy workspace:

Factory URL - Private WorkspacePermissions
Can be created by:Codenvy users with relevant permissions for the workspace
Can be used by:Named users
Temporary workspace:Private – accessible only by the user who created it
Collaboration sessions:Disabled

If you want to create a publicly accessible Factory so that anyone can use it, you have to turn your project into public.

Factory for Public vs. Private git Repositories

Factories can be created using any git repository. When you create a Factory from Codenvy, it uses a local clone git repository that we keep for your workspace, but you can also manually create a Factory URL that uses any external git repository.

Follow the link to learn more about the Factory URL Format and Specification.

Factory for Public git Repositories

Codenvy supports a number of git hosting providers. If a repository is public there are no restriction on who can create it.

You can create a Factory for your project using an external public git repository by providing all mandatory parameters (See:Factory URL Format and Specifications). Below is a set of mandatory Factory URL parameters and a sample URL using these parameters:

ParameterValue
v1.0
vcsgit
vcsurlhttps://github.com/karlsson82/vaadin.git
idcommit58c6ba3fdc0c89371aafc14b4a89745f19620f3e
pnamevaadin_app
ptypewar


https://codenvy.com/factory?v=1.0&pname=vaadin_app&vcs=git&vcsurl=https://github.com/karlsson82/vaadin.git&idcommit=58c6ba3fdc0c89371aafc14b4a89745f19620f3e&ptype=war

Codenvy Factory - External Public Git RepositoriesPermissions
Can be manually created by:Anyone – no need to be a Codenvy user
Can be used by:Named or anonymous users
Temporary workspace:Public - can be shared
Collaboration sessions:Enabled

Factory for Private Git Repositories

If you have a private remote git repository, you can still create a Factory that will keep privacy restrictions applied to your repository. Creating a temporary workspace and cloning a project will be restricted to users who can authenticate and access your repository.

The workflow is a little bit different as when we start cloning a project, we will also detect if the repository is private or not. Depending on the git vendor you are using, we will ask you to authenticate with it:

private_git_repo

We support two authentication types :

  • OAuth
  • Basic Authentication over HTTPS

You can create a Factory for your project using a private git repository by providing all mandatory parameters described in the Factory URL Format and Specification.
We’ve also added an additional parameter called ‘privaterepo’ that will be used to speed up cloning of a private git repository.

For example:

ParameterValue
v1.0
vcsgit
vcsurlhttps://github.com/karlsson82/vaadin.git
idcommit58c6ba3fdc0c89371aafc14b4a89745f19620f3e
pnamevaadin_app
ptypewar
privaterepotrue

This will produce the following Factory URL:


https://codenvy.com/factory?v=1.0&pname=HelloSpringMVC&vcs=git&vcsurl=https://github.com/karlsson82/vaadin.git&idcommit=58c6ba3fdc0c89371aafc14b4a89745f19620f3e&ptype=War&privaterepo=true

Codenvy Factory - External Private Git RepositoriesPermissions
Can be manually created by:Anyone – no need to be a Codenvy user
Can be used by:Named or anonymous users
Temporary workspace:Private – accessible only by the user who created it
Collaboration sessions:Disabled

Using a Factory

There are various ways to find a Factory for use:

  • Someone sends you a Factory URL
  • You see a Factory icon that is the front-end to a Factory
  • You browse the list of Factories available on Codenvy web site
  • A Factory is embedded in another product that you are using

Clicking a Factory Button

Clicking a Factory button will initiate creation of a temporary workspace and cloning of a targeted project. Buttons can be embedded into webpages. You can get a project’s Factory URL at Share > Factory URL.

factory_menu

While a Factory is a simple URL, we have created a standard visual look to front-end the Factory URL:

The button format for a Factory URL has been standardized with a set of colors, shapes, sizes, and animations. You can see the complete specifications for the button here.

Clicking a URL

Clicking a Factory URL does not differ from clicking a Factory button in terms of system behavior. The way to share Factories is the only difference – while Factory URL can be shared directly, for instance via IMs, buttons are embedded to web page source code.

Using a Factory While Authenticated with a Codenvy Account

When clicking a Factory URL a temporary workspace will be created both for authenticated and non-authenticated users. Authenticated users (those having a Codenvy account and logged in when clicking a Factory URL) can copy a project that has been cloned just after creation of a workspace to their permanent workspace. This also concerns any new projects that a user will create while using a temporary workspace. An authenticated user will see the below button in the top right corner of the workspace:

copy_to_workspace

Authenticated users can also:

  • view and change profile details from a temporary workspace
  • add and delete SSH keys (since they are saved in a user’s profile)

Using a Factory While Not Authenticated with a Codenvy Account

Non-authenticated users have basically the same functionality, except that they do not have a profile, and previously generated SSH keys. Non-authenticated users do not have Copy to my workspace button since they do not have a temporary workspace. There are two options for non-authenticated users to do so:

  • login (you will see login button  in the top right corner of a temporary workspace)
  • create an account (you will see create_account button in the top right corner of a temporary workspace)

Adding Users to a Factory Session – Collaboration

If two or more users access the same temporary workspace, they will be able to work in a collaboration mode. So, to collaborate on a project in a temporary workspace just share its URL. This does not work for a Factory URL, since every time this URL is clicked on a new temporary workspace is created. A workspace URL must be shared.