Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
How you interact with EasyCLA depends on your role. EasyCLA supports the following roles in its workflow:
When a Contributor License Agreement (CCLA) is first implemented, the roles of Contributor, CLA Manager, and CLA Signatory may be held by the same individual or different people. Each contributing company decides which employees will fill these roles.
Understanding these roles is essential to determine who should be designated for each position. Review the following roles to facilitate discussions with your company's management and legal counsel.
A Project Manager is typically a project administrator or maintainer responsible for setting up the project's CLA templates and configuring the corresponding repositories in the EasyCLA Project Console (also called Project Control Center). For more details, see Project Managers.
A contributor is typically a developer contributing code to a GitHub or Gerrit project set up on EasyCLA.
The specific workflow a contributor follows depends on two factors:
Whether the project is hosted on GitHub or Gerrit.
Whether they are contributing on their behalf or behalf of a company (usually their employer).
After submitting a contribution to GitHub or Gerrit, a contributor who has not yet been authorized under a signed CLA will initially encounter a block. To resolve this, they will use the EasyCLA Contributor Console to either:
Sign an Individual Contributor License Agreement (ICLA) if contributing on their behalf.
Identify the company on whose behalf they are contributing, allowing them to either be authorized under a signed Corporate Contributor License Agreement (CCLA) or initiate the CCLA signing process.
A CLA manager is an individual authorized by a company to manage the list of authorized contributors and other CLA managers under that company's Corporate Contributor License Agreement (CCLA) for a project.
A CLA Manager uses the EasyCLA Corporate Console to:
When a CCLA is first being set up for signature, it will specify an "Initial CLA Manager." This person uses the EasyCLA Corporate Console to coordinate the signing of the CLA (see CLA Signatory below).
After the CCLA is fully signed, the specified Initial CLA Manager can use the EasyCLA Corporate Console to manage the list of authorized contributors. They can also designate additional CLA managers.
By default, a CLA manager is not automatically an authorized contributor themselves, unless they add themselves to the authorized contributor list.
A CLA signatory is an individual authorized by their company to sign a Corporate Contributor License Agreement (CCLA) on its behalf.
If a company's CLA signatory is the same as their initial CLA manager, they will be redirected to sign the CCLA via the EasyCLA Corporate Console.
If the CLA signatory is a different person from the initial CLA manager, the CLA signatory will receive an email to review and sign the CCLA.
If you are authorized and receive an email request to sign contracts, then review and sign the project’s CLA on behalf of the company.
The following issues are known to be present in the v2.0.0 release of EasyCLA:
Auto-Branch Protection only protects a repo's default git branch. Non-default branches are not currently auto-configured for EasyCLA protection. Currently, GitHub/GitLab organization owners must manually set up branch protection rules for non-default branches.
Currently, user roles in EasyCLA can only be associated with a single company or organization at a time.
Release notes for the EasyCLA backend and APIs can be found at https://github.com/communitybridge/easycla/releases.
Release notes for the EasyCLA Contributor Console can be found at https://github.com/communitybridge/easycla-contributor-console/releases
EasyCLA V2.0 supports projects with a parent-child model of any number of hierarchy levels without any limit in the depth of the hierarchy. The following is an example:
Parent Project
Child Project
Grand Child Project
Great Grand Child Project
Great-Great Grand Child Project
….
To utilize EasyCLA, a project must adhere to the following criteria:
Linux Foundation Hosting: EasyCLA is tailored exclusively for projects under the Linux Foundation umbrella. Projects or repositories hosted elsewhere are not supported.
This service is incompatible with projects or repositories outside the Linux Foundation.
Supported Platforms: Projects must be hosted on GitHub, Gerrit, or GitLab.
Gerrit Requirements: The Gerrit instance must be hosted by the Linux Foundation for projects using Gerrit.
Repository Settings: Repository administrators are required to enable Branch Restrictions and Branch Protection on GitHub or GitLab. These settings must enforce required status checks on branches, irrespective of the organization member's role.
CLA Managers seeking access to EasyCLA must have an LF Single Sign-On (SSO) account. To create an LF SSO account, visit Creating an LF SSO Account.
For a project to use EasyCLA, it must meet the following requirements:
For a company to sign a project's CCLA, they must identify the appropriate company employees who will be the CLA Manager and CLA Signatory for that CCLA.
LFX EasyCLA is the only CLA management tool to correctly support both individual and corporate CLA workflows in an automated environment.
Streamlined Workflows: Simplifies workflows for project maintainers, contributors, and organizations with contributing employees.
Automated Processes: Coordinates the process of getting CLAs signed and authorizing employees to contribute under a signed CLA.
Open Source: Hosted by The Linux Foundation, this open source solution automates manual processes.
Reduced Delays: Helps developers quickly get authorized under a CLA.
Efficient Contributions: Streamlines the contribution process for open source projects that use CLAs.
Contributor License Agreements (CLAs) are facilitated by LFX EasyCLA, ensuring a smooth and efficient contribution process for all parties involved.
Some projects use a Contributor License Agreement (CLA) to define the terms under which content (such as source code or documentation) is contributed to the project.
Not all projects use CLAs; many use alternative contribution mechanisms, such as the Developer Certificate of Origin sign-off process. For those who do use CLAs, LFX EasyCLA helps to ensure that contributions are not merged into a project unless the contributors are covered under a signed CLA.
There are two types of CLAs:
Corporate Contributor License Agreement (CCLA)
If a contribution is made on behalf of a company (usually the contributor’s employer), it should be done using a CCLA. The person signing the CCLA must have the authority to enter into legal contracts on behalf of the company, which is often not the contributor.
Once a company signs a CCLA, the CLA Manager will utilize the EasyCLA Corporate Console to oversee the authorized contributors list.
Individual Contributor License Agreement (ICLA)
Contributors who own their contributions should sign an ICLA before their contributions can be merged into the project repository.
For either a CCLA or an ICLA, after the contributor is authorized under a signed CLA, they will be able to contribute to that project without being blocked by the EasyCLA checks.
Following is a high-level diagram, showing the different flows and roles that EasyCLA supports:
EasyCLA Project Console for a project's director or manager (typically an LF staff member) to oversee the project's CLA setup. It is sometimes referred to as the LFX Project Control Center in this documentation.
EasyCLA Contributor Console for a contributor to a project to sign an Individual CLA (ICLA), or to start the corporate CLA (CCLA) signature process.
EasyCLA Corporate Console for a company's CLA Manager to coordinate the corporate CLA signature process, and then manage their company's authorized contributors.
For information about contributing to a project that uses EasyCLA, please see Getting Started and our FAQs page.
For support questions, see our Troubleshooting page or file a support ticket.
If you are having issues with EasyCLA, go to , and file a ticket.
The following sections help you troubleshoot common problems that you might encounter when using the EasyCLA tool.
I have an agreement on file, but EasyCLA does not authorize me and displays "Missing ID on Commit".
If your commits are linked to your GitHub account, and yet the GitHub pull request is not passing the EasyCLA check, then open the pull request, type/easycla
in the comment box, click Comment as shown below. This runs the EasyCLA bot again, and the GitHub pull request is passed.
Contributors' commits are linked to their GitHub accounts, however, they are still facing issues contributing to EasyCLA-enforced repositories.
Or
Contributor's commits are linked to Gerrit account, however, they are still having trouble contributing to EasyCLA-enforced repositories.
Ensure that your Gerrit email address is added to the approved list, and you must log in to the Gerrit instance of your project using the same email address that is added to the approved list.
After a Contributor has signed an ICLA, EasyCLA status is not updated on the contributor console.
It may take a few moments for the status of the EasyCLA checks to update. Please wait a few moments and then refresh the page. **** If the EasyCLA status is still not updated, open the pull request, and comment /easycla
in the comment section as shown below. This comment runs the bot again. If the status still does not change, open a support ticket.
After a Contributor has signed an ICLA, EasyCLA status on Git command line still displays "No contributor agreement" when the contributor pushes the code change.
For a CCLA, after a Contributor has been added to the approved list for the first time, the CLA status still displays Not Covered.
For a CCLA, after a contributor has been added to the approved list for the first time, the CLA status on the Git command line still displays No contributor agreement when you push the code change.
Navigate to the Gerrit window, sign out, sign in again, and then push the code.
In the “Checks” section of the pull request, EasyCLA status is showing as “Expected”.
Open the pull request, and comment /easycla
in the comment section as shown in the image below. This comment runs the bot again. If the status still does not change, open a support ticket.
After signing an ICLA or verifying under a CCLA, the status does not change to “Authorized” for multiple open pull requests.
Open one pull request, and comment /easycla
in the comment section as shown in the image below. This comment runs the bot again. If the status still does not change, open a support ticket.
After hosting my project on The Linux Foundation, I can not use EasyCLA for my project.
When I am trying to contribute code under a CCLA, my company is not displayed in the list.
I have signed an ICLA; however, I cannot view the signed ICLA.
Open your email, that you have provided while signing the ICLA, to check the signed ICLA that is sent from The Linux Foundation. If you have not received the email, you can open a support ticket to have it resent.
Ensure that your commits are . If your commits are not linked to any GitHub user, GitHub will display the grey Octocat logo beside the commits.
If your CLA Manager has approved your company email address or email domain, ensure that your company email is and make sure your GitHub email address is public.
If your CLA Manager has approved your GitHub Organization,.
Navigate to the Gerrit window, sign out, sign in again, and then push the code.
After being added to the approved list under their company's signed CCLA, the Contributor must . This is a one-time action and, after completion, it will not be required for future contributions to that project.
Although it is uncommon, some projects may require a Contributor under a CCLA to additionally . If this is required, then after completing the company acknowledgement, the Contributor will be guided to sign the project's ICLA.
Open , submit the form describing your requirements, and import your existing CLAs.
You must create a record for your company as described .
Who do I contact to enable my Linux Foundation-hosted project to use EasyCLA?
Open https://jira.linuxfoundation.org/plugins/servlet/theme/portal/4/create/143, submit the form describing your requirements and import your existing CLAs.
Why does The Linux Foundation ask contributors of some projects to sign CLAs?
Some project communities have elected to use CLAs as a required step for code contributions. The Linux Foundation wants to ensure that contributions comply with the IP (Intellectual Property) policies of that project.
What is the difference between a Corporate CLA (CCLA) and an Individual CLA (ICLA)?
A Corporate CLA needs to be in place if you are contributing code on behalf of your employer. A Corporate CLA should be signed by an individual who is authorized to enter into legal agreement on behalf of the company. After the Corporate CLA is signed, your email address needs to be included in an approved list for the project. A CCLA manager for your company is responsible for managing the approved list.
An Individual CLA is signed by an individual for contributions that they contribute on their own behalf, as opposed to contributions on behalf of their employer or another entity.
How can I contribute to GitHub/Gerrit/GitLab repositories?
If you are an individual contributor, see Individual Contributor. If you are a corporate contributor, see Corporate Contributor for details.
Open your email, which you provided while signing the ICLA, to check the signed ICLA that was sent from The Linux Foundation. If you have not received the email, you can open a support ticket to have it resent.
Using the Domain Approval Criteria requires less overhead because CCLA signatories and CCLA managers do not need to add and manage numerous employee email addresses.
Probably not. If your company's CCLA signatory has signed a Corporate CLA, and if you are included in the approved list under that company's CLA, then you simply confirm your association with the company during your code submission process.
However, if you are the first one from your company to contribute to a project, then your company's CCLA signatory will need to sign a Corporate CLA as part of the EasyCLA setup process. Depending on the company, you might be an authorized CCLA signatory (please check with the legal counsel of your company to be sure).
Otherwise, if your company has already signed a Corporate CLA but you are not yet on your company's approved list, you must be included on the approved list by your company's CCLA manager as part of the EasyCLA process.
When I am trying to contribute code under a CCLA, what should I do if my company is not listed?
You must add your company as described here before you can contribute code under corporate CLA (CCLA).
If my project community has elected to use CLAs as a required step for contributions to their code, do I need to be authorized under a CLA for each project to which I contribute?
Yes, provided that the project has a CLA.
If you are contributing as an individual—you must sign an Individual CLA for each project to which you contribute.
If you are contributing as an employee of a company, your company's CCLA signatory must sign a Corporate CLA.
Do I have to sign a CLA every time I contribute code to a project?
If you have already signed CLA for a project, then you don't need to sign every time to contribute to the project. Signing a CLA for a project covers all code contributions to that project. You may, however, need to sign additional CLAs if you choose to contribute to other projects that require CLAs.
Your ICLA will be emailed to the email address you provided when signing it, as soon as you sign it. If you did not receive the email, you can open a support ticket to have it resent.
(Individual Contributors) Wait for the few seconds or refresh the page to get your EasyCLA status updated.
(Corporate Contributors) After you complete the process, you must acknowledge acknowledging company contribution. If you have already acknowledged company contributions, wait for few seconds or refresh the page to get your EasyCLA status updated.
Why does EasyCLA redirect and update a previously opened PR instead of the one I performed the signature on?
When there are two or more opened PRs in the same repository, during the signature process, EasyCLA will always redirect and update the earliest opened PR. Once the signature has been completed, you can add a "/easycla"
comment on the other PRs to trigger the EasyCLA bot and update your authorization status for each open PR.
The cla/linuxfoundation check on my PR for a Kubernetes repo is not marked as passed after signing the CNCF CLA through EasyCLA?
Kubernetes repositories are in the process of migrating from CLA v1 (cla/linuxfoundation check) to EasyCLA (EasyCLA check). During this migration, the cla/linuxfoundation check is not being updated even when the users have properly signed the CLA. If the PR has the label "cncf-cla: yes," it means the authorization for the user has been granted. Note that the cla/linuxfoundation check is neither a requirement nor a blocker for merging the PR once all the required labels have been included.
Once the migration has been completed cla/linuxfoundation check will be removed.
What is the acceptable email format?
A valid email address with an email prefix and an email domain, for example, abc@mail.com
The allowed characters for the email prefix are letters (a-z), numbers, underscores, periods, and dashes, and an underscore, period, or dash must be followed by one or more letters or numbers, for example: abc-d@mail.com/abc.def@mail.com/abc@mail.com/abc_def@mail.com
The allowed characters for an email domain are letters, numbers, and dashes, and the last portion of the domain must be at least two characters, for example,.org,.cc.
A Project Manager can sign in to the EasyCLA Project Control Center to perform the CLA set-up and management tasks for projects that you manage.
To Sign in:
Go to .
Click Sign in with SSO.
Enter your credentials as the Project Manager and click Sign In.
EasyCLA was previously enabled for a GitHub repository, but someone other than the project manager has subsequently disabled it.
GitHub is set up to permit administrators and organization owners to have maximum flexibility, which includes disabling installed applications, such as EasyCLA. To avoid this, you must enable branch protection by after the GitHub organization is added to a project.
You can also add the branch protection rule manually, as described below:
1. As the GitHub organization owner or administrator, go to the GitHub repository that you want EasyCLA to monitor.
2. Click Settings from the top menu.
3. Settings appear with Options in the left pane.
4. Click Branches under Options.
5. Select master for the Default branch. Click Edit or Add rule for Branch protection rules of your organization.
6. Select the following check boxes under Rule settings, and click Create:
Require status checks to pass before merging
Require branches to be up to date before merging
Include administrators
4. Click a project to view more about the project or search for a project from the left navigation pane. For details, see .
A Project Manager can view CLA group details and update CLA group details by updating or deleting a CLA group name, updating a CLA template, and invalidating a contributor's signature.
Sign in to the Project Control Center.
Click a project name of interest.
Scroll down to the Tools Status section, and click EasyCLA. The EasyCLA Overview page appears.
The Overview page displays CLA groups that have been added to the project, details for each CLA group, and an activity log table. A CLA group defines a CCLA and/or ICLA that contributors must sign.
1. Name of the CLA group, and whether the CLA Group includes a CCLA and/or an ICLA with a tick mark beside each CLA type.
Projects Covered shows the number of projects covered under the CLA group.
Repositories show the total number of repositories of the added projects that are enrolled for CLA monitoring. You must enforce EasyCLA for one or more Git repositories for them to be counted.
Signatures shows the number of individuals who have signed CLA within that CLA group, and whose signature status is in active state. This includes both ICLA and/or CCLA based on the CLA group configuration.
Click the pencil icon to edit the title and description of the CLA group.
2. Under the PROJECTS tab, expand the project group to view projects that are enrolled for the CLA group. Inactive selected check boxes indicate that the project has already been added to another CLA group. Click Manage to add and manage GitHub, Gerrit, or GitLab groups and repositories.
3. Navigate to the TEMPLATES tab to view and download the ICLA and/or CCLA templates. You can update the templates in case the email address mentioned in the template is not correct or you want to change it.
Navigate to SIGNATURES tab to view signed ICLAs and CCLAs.
Signed ICLAs lists details of individuals who have signed an ICLA, such as name, LF Login name (LF ID), GitHub ID, email address, status of their signature (Active, Disabled, Invalidated), and Invalidate CTA under Actions column (enabled only for Active statuses). Following are the different signature statuses:
Active: The contributor has completed the CLA signing process.
Incomplete: The contributor has not completed the CLA signing process.
Disabled: Either the project manager has invalidated the signature of the contributor or the CLA manager has removed the contributor's approved criteria from the approved criteria list on the corporate CLA console.
Signed CCLAs list the details of companies that have signed a CCLA. It lists the company name, CLA Managers, approved contributors, approval criteria for the approved contributors, the signed CCLA document, and the date.
It shows the recent CLA activities for the projects within the CLA group, such as activity description, name of the person who did the activity, date and time of the activity, the corresponding company name where applicable, and the applicable project.
Clickto create a support ticket requesting to delete the CLA group.
Project managers can edit and update CLA templates to display the correct email address of the person managing the project so that contributors can submit signed CLAs to the mentioned email addresses if they want to sign them manually, rather than via DocuSign.
1. Sign in to the Project Control Center.
2. Under My Projects, click a project, and scroll down to Tools Status section, and click EasyCLA.
3. Under CLA Groups, select a CLA group for which you want to update templates.
4. Navigate to TEMPLATES tab, and click Edit Template.
5. Provide email address of the person managing the project in the respective field, and click Update Template.
Note: This email address is displayed in the CLA templates as the email address for contributors to submit signed CLAs if they want to sign them manually, rather than via DocuSign.
6. Click Update Template.
Before you can add or manage GitHub organizations and repositories, you must connect or add GitHub organizations while setting up IT services. However, you can also add GitHub organization in the GitHub pane of Tools tab.
After you successfully add GitHub organization, you can:
Prerequisite: You must be the owner of the GitHub organization which you want to connect for CLA mechanism.
1. Sign in to the Project Control Center.
2. Click a project of interest.
3. Scroll down to the Tools Status section, and click EasyCLA.
Note: You can also connect the GitHub organization during IT set up in the IT Services Status section, and then install EasyCLA application in Tools Status section to add it for CLA process.
4. Under CLA Groups, select a CLA group to which you have added the project.
5. Click Manage next to the project for which you want to manage repositories.
6. Under the GitHub tab, click the + sign at the top right of Add GitHub Organization.
7. Type the GitHub organization name in the Enter GitHub Organization field, and click Connect.
8. Click Install GitHub EasyCLA App.
9. Sign in to GitHub if the sign-in window appears, and click Configure.
10. Select the organization that you want to enroll for CLA mechanism.
11. Select repositories, and click Install.
Note:
If you select Only select repositories, then a newly added repository to the GitHub organization will not be reflected automatically under the project's GitHub organization page in Project Console.
12. Navigate to the Project Control Center, and click I'm Done Installing.
Important: To enable a CLA mechanism on a repository, you must enforce CLA mechanism for GitHub repositories. Simply adding a GitHub organization to the project does not enable the EasyCLA mechanism for any CLA groups.
After adding the GitHub organization, you should enable branch protection and auto enable new repositories.
Enable Branch Protection automatically enables the EasyCLA check for all the branches of the GitHub organization. If you select this check box, you do not need to enable branch protection manually.
Auto Enable New Repositories automatically adds a repository under the GitHub organization on the project console when you add the repository to the GitHub organization.
2. Click both the check boxes, and click Save Changes.
2. Click Disassociate GitHub Org, and click the link to create a support ticket to disassociate the GitHub org.
The Project Manager can add new projects to a CLA group or remove projects from a CLA group.
Sign in to the Project Control Center.
Under My Projects, click a project.
Scroll down to Tools Status section, and click EasyCLA.
Under CLA Groups, select a CLA group for which you want to manage projects.
Select or deselect the check box next to a project to add or remove the project from the CLA group.
Click Update CLA Group.
Note: A project's check box is selected and unavailable under a CLA group if the project has already been added to another CLA group.
1. Click the settings icon next to Additional Settings for a GitHub organization.
1. Click the settings icon next to Additional Settings for a GitHub organization.
This document provides a detail description of LFX EasyCLA application, and how to use the application based on your access role.
To get started with the application, see the Getting Started page, and for any troubleshooting related information, see the Troubleshooting page.
Before you can add or manage GitLab groups and projects, you must connect or add GitLab groups while setting up IT services. However, you can also add GitLab groups in the GitLab pane of Tools tab.
Note:
In GitLab, organizations are mentioned as groups, and repositories are mentioned as projects.
You must be the owner of the GitLab group which you want to connect for CLA mechanism.
After you successfully add Git organizations, you can:
1. Sign in to the Project Control Center.
2. Click a project of interest.
3. Scroll down to the Tools Status section, and click EasyCLA.
Note: You can also connect the GitLab groups during IT setup in the IT Services Status section, and then install the EasyCLA application in the Tools Status section to add it for the CLA process.
4. Under CLA Groups, select a CLA group to which you have added the project.
5. Click Manage next to the project for which you want to manage repositories.
6. Under the GITLAB tab, click the + sign at the top right of ADD GITLAB GROUP.
7. Provide the complete URL of the GitLab group, as shown in the image, in the Enter GitLab Group URL field, and click Connect.
8. Click Install GitLab EasyCLA App.
9. Click Authorize.
10. Installation Successful window appears. Close the window, navigate to the Project Control Center, and click I'm Done Installing.
Note: If you do not click I'm Done Installing, you will have to reinstall EasyCLA application.
Note:
1.LFX EasyCLA adds all the projects, including projects under subgroups, of the GitLab group to the Project Control Center.
2.To enable a CLA mechanism on a project, you must enforce CLA mechanism for GitLab projects. Simply adding a GitLab group to the project does not enable the EasyCLA mechanism for any GitLab project.
3.To review the configuration or revoke the application, navigate to the GitLab Applications under your User Settings.
After adding the GitLab group, you should enable branch protection and auto enable new repositories.
Enable Branch Protection automatically enables the EasyCLA check for all the branches of the GitLab group. If you select this check box, you do not need to enable branch protection manually.
Auto Enable New Repositories automatically adds a repository under the GitLab group on the project console when you add a project to the GitLab group.
To enable branch protection and auto enable new repositories:
2. Click both the check boxes, and click Save Changes.
Note: To disassociate a GitLab group, you must disable CLA from all projects of the GitLab group.
Click Disassociate GitLab Group, and click Disassociate on the confirmation window.
After you add a GitHub or Gerrit organization or GitLab group, the organizations or groups are displayed with different colors referring to their connection statuses. The following is an example:
indicates full connection: all the repositories of the organization are connected.
indicates partial connection: some repositories of the organization are connected.
indicates no connection: the organization is added, but its repositories are not EasyCLA enforced.
indicates connection failure: for a connected organization, either the EasyCLA configuration is uninstalled or the organization is deleted from GitHub/Gerrit/GitLab.
A repository with a cross mark next to it indicates connection failure. It means the repository was EasyCLA enabled, but it is deleted from the organization.
Before you can add or manage Gerrit organizations and repositories, you must connect or add Gerrit organizations while setting up IT services. However, you can also add Gerrit organization in the Gerrit pane of Tools tab.
After you successfully add Git organizations, you can:
Note:
If you have already added a Gerrit instance during the EasyCLA on-boarding process, skip this procedure unless you want to add more Gerrit instances.
After you add a Gerrit organization, all of its repositories are EasyCLA-enabled by default.
1. Click the + sign at the top right of Add Gerrit Organization.
2. Complete the form fields, and click Connect.
Gerrit Instance Name - Name of the Gerrit Instance
Gerrit Instance URL - URL of the Gerrit Instance
ICLA Group ID - An existing LDAP Group ID for Individual CLAs
CCLA Group ID - An existing LDAP Group ID for Corporate CLAs
Notes:
Contact the Linux Foundation IT team to get Gerrit Instance Name and URL.
Contact the Linux Foundation IT team if you do not know the LDAP Group IDs.
One or both LDAP groups must exist for you to be able to create a Gerrit instance. If a group does not exist, an error message appears and you are prevented from creating a Gerrit instance.
The EasyCLA project console lists the CLA-enabled instances, as shown below.
Note: You cannot disable the CLA check for individual Gerrit repositories.
1. Click Disassociate Gerrit next to a Gerrit Instance, and click Yes, Disconnect on the confirmation page.
Project Managers can anytime invalidate a contributor's signature for any valid reason, for example when a contributor leaves the organization.
Sign in to the .
Click a project name of interest.
Scroll down to Tools Status section, and click EasyCLA. The EasyCLA Overview page appears.
Navigate to Signatures tab.
From Signed ICLAs tab, under Actions column, click Invalidate .