eclipsefdn / git-eca-rest-api Goto Github PK

View Code? Open in Web Editor NEW

0.0 10.0 9.0 215 KB

License: Eclipse Public License 2.0

Java 92.58% Ruby 4.69% HTML 2.73%

quarkus webdev

git-eca-rest-api's Introduction

git-eca-rest-api

NOTE

This project was migrated to Eclipse Gitlab on October 14, 2021.

This project uses Quarkus, the Supersonic Subatomic Java Framework.

If you want to learn more about Quarkus, please visit its website: https://quarkus.io/ .

What is a valid commit?
Submitting applications for existing bots
Running the application in dev mode
Packaging and running the application
Enabling commit hook in GitLab

What is a valid commit?

To be considered a valid commit, the following set of rules are checked against all commits that are submitted to this service. If any fail and the commit is related to a project, the service returns a message indicating the commit is not suitable for submission along with messages as hints.

All users that commit to a project within the Eclipse space must have a signed ECA, and therefore, Eclipse accounts.
- The one exception to this rule is registered bot users, as they cannot sign an ECA.
- Users covered by an MCCA are also covered, as it is considered an equivalent document in the eyes of contribution access.
Contributing users must sign off on their commits using the Signed-off-by footer (example below). example) Signed-off-by: Martin Lowe [email protected]
- Bot users and committers for a project are exempt from this rule, as they are covered by other agreements. If a bot is required for a project, it can be registered through the bot API.
- When committing to a project, a bot must be registered to the particular project or the commit is rejected (#45).
- Additionally, if a bot user makes a commit to a repository from an email address tracked for a different service, that commit is still considered valid (#45).
The committing user must be the same as the authoring user.
- The one exception to this is when the committing user is a project committer, who may commit on behalf of other users
Requests made to non-project repositories by default will be allowed to pass with warnings to enable ECA validation to be run across a system with projects or repositories not directly managed by the Eclipse Foundation, such as forks or supporting projects (#26).
- Within the API, a request can be made under 'strict mode' to enforce contribution guidelines within repositories not covered by an active project (#43).

While these rules apply to all project repositories, any non-project repositories will also be checked. The messages indicate the failures as warnings to the consuming service (like Gitlab or Gerrit) unless 'strict mode' is enabled for the service. Whether or not a repository is tracked (or if it is a project repository) is determined by its presence as a repository directly linked to an active project within the PMI, as reported by the Projects API.

Submitting applications for existing bots

To submit requests for existing bots to be registered within our API (such as dependabot), please see the Project Bots API repository and create an issue.

Running the application in dev mode

You can run your application in dev mode that enables live coding using:

./mvnw quarkus:dev

Packaging and running the application

The application is packageable using ./mvnw package. It produces the executable git-eca-rest-api-0.0.1-runner.jar file in /target directory. Be aware that it’s not an über-jar as the dependencies are copied into the target/lib directory.

The application is now runnable using java -jar target/git-eca-rest-api-0.0.1-runner.jar.

Enabling commit hook in GitLab

To enable the Git hook that makes use of this service, a running GitLab instance will be needed with shell access. This instruction set assumes that the running GitLab instance runs using the Omnibus set up rather than the source. For the differences in process, please see the GitLab custom hook administration instructions. Once obtained, the following steps can be used to start or update the hook.

Access the GitLab server shell, and create a folder at /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/ if it doesn't already exist. This folder will contain all of the servers global Git hooks for pre-receive events. These hooks trigger when a user attempts to push information to the server.
In the host machine, copy the ECA script to the newly created folder. If using a docker container, this can be done with a call similar to the following:
docker cp src/main/rb/eca.rb gitlab.eca_web_1:/opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/
In the GitLab shell once again, ensure that the newly copied script matches the folders ownership, and that the file permissions are 755. This allows the server to properly run the hook when needed.

git-eca-rest-api's People

Contributors

Watchers

Forkers

autumnfound akondasif paser4se chrisguindon isabella232 global-localhost global19 global19-atlassian-net bchooiii

git-eca-rest-api's Issues

Conflicting documentation in readme.md

The committing user must be the same as the authoring user.
The one exception to this is when the committing user is a project committer, who may commit on behalf of other users

@waynebeaton @autumnfound,

I don't believe this is true. As far as I know, we don't need to check the committer field, we only need to validate the author's field.

Intermittent issues when checking commits (timeouts)

When the server gets a cold hit, it tends to timeout before a response can be given. This is likely caused by the current implementation of the project fetching API. We should probably precache this once an hour (or per period) and have the services start on boot rather than lazily initialize

When creating a new branch, a push will fail if an old commit offends the ECA check

If an old commit does not pass the ECA check (anymore), how can this be fixed or circumvented?

Are proxy commits still blocked for non-committers

Coming from the Gerrit validation logic, we have logic in the ECA service that checks whether the committer is the same as the author. If they are different and the project is tracked (like within PMI), the committer needs to be a committer on the project, otherwise the commit is rejected.

@chrisguindon had told me that this is no longer a requirement and is not a legal issue. I wanted to check in whether these proxy commits still need to be checked, or if we only care about the authors.

//cc @waynebeaton

Cannot create revert for MR from UI

When attempting to revert a merge commit in GitLab, the following message appears:

The contributor must "sign-off" on the contribution.

This is due to the lack of -s flag in the merge commit command being issued by GitLab. We should make a request for support to GitLab to see if it's possible to tweak this commit command to add the -s flag (as there is no indication of the setting in the documentation).

Srcs:
https://docs.gitlab.com/ee/user/project/merge_requests/revert_changes.html#reverting-a-commit
https://git-scm.com/docs/git-revert#Documentation/git-revert.txt--s

GitLab pre-recieve hook: Merges being denied

When attempting to merge in branches, merge commits are being rebuffed rather than skipped for processing. This is likely due to parents not being properly processed and passed from the hook script.

The author has not signed-off on the contribution

The signed-off-by validation is failing if it's not the last line:

commit e8c6da660643bcc77ea33d399f6a90e7c6d11e6b (HEAD -> cguindon/test/eca)
Author: Christopher Guindon <[email protected]>
Date:   Tue Dec 8 16:06:52 2020 -0500

    add readme.md
    
    Signed-off-by: Christopher Guindon <[email protected]>
    Change-Id: I139e2d803770ef65e55645e2d499731ffb749300

Result:

 ! [remote rejected] HEAD -> refs/for/master (commit e8c6da6: The contributor must sign-off on the contribution.)
error: failed to push some refs to '../webdev/devops'

The workaround is to move the sign-off-by section after the Change-Id. However, we can't expect our users to do that. The requirement is simply to include the in the footer section of a commit message.

[gitlab] - each commit is reviewed twice

As reported by Antonio Garcia-Dominguez, the Gitlab ECA service is reviewing commits twice:
https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/7#note_73

Clarify error message when a commit is rejected on website repos

Right now if a committer tries to submit a change on a website repo without the signed-off-by footer the returned error message includes the line:

"The author is not a committer on the project"

This is clearly confusing some people as they aren't seeing past that warning to see the 'missing signed-off-by' which is what is actually blocking their change. To be fair not having permissions does seem like a more serious error, rather than a missing footer.

Can that line be suppressed in some way when people commit to the website repos?

Signed-off-by validation does not support multiple authors

We are currently validating the first appearance of a "Signed-off-by" but a contribution might include multiple Signed-off-by.

The order is not important in the commit message but we need to make sure that the author did include their Signed-off-by in the commit message. This is not a requirement if the author is a committer on the project.

We also need to make sure that the contributor has an ECA but we are already doing that!

Minor formatting issues in ECA check result

Commit: 7h15154r4nd0m5h4h45h
		✔

	Reviewing commit: 7h15154r4nd0m5h4h45h
	Authored by: Bart Simpson
 <[email protected]
>
	The author is a committer on the project.
Any warnings noted above may indicate compliance issues with committer ECA requirements. More information may be found on https://www.eclipse.org/legal/ECA.php)

There is an unnecessary line break after the first line and right after the email address. I guess there should not even be a line break between the author name and the email address.

Dependabot commits always fail ECA validation

In terms of what the service is checking, failure is the correct answer, but we should probably look at how we validate users to see if there is a clean way of handling accounts like dependabot (widespread usage external bots).

Tabs in commit messages causing parse failures in ECA rb pre-receive hook

Parse failures encountered when tabs were included in the commit messages. https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/5#note_144

We should scrub these out and replace with a few spaces instead.

Cannot push initial branch for tracked repo

This issue was reported on the Gitlab instance when attempting to push a master branch to a new repo. https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/36#note_6619. If the new repo is already tracked before a branch is created, this could present an issue. We should also try to check whether there is a HEAD/main to compare to, as there is some funky behavior when there isn't one:

remote: fatal: unknown commit refs/heads/main
remote: Commit: _nil            ~
remote:
remote:
remote: Warnings:
remote:         A commit is required to validate
remote: Any warnings or errors noted above may indicate compliance issues with committer ECA requirements. More information may be found on https://www.eclipse.org/legal/ECA.php
remote:
remote:
To gitlab.eclipse.org:eclipse/titan/test.git

Tech debt: Use Link headers to paginate rather than manual pagination

Current Project API pagination is brittle due to the current manual method of pagination within the ProjectsService. This was done as an acceptable stopgap to go live, and a better fix that makes use of Link Headers should be used.

On the initial investigation, there was no found way to easily extend the RESTeasy API builder model. If this model can be extended, then adding a post-process to the responses to attach Link headers to the response output can be used to more sustainably iterate over the data. If there is no way to extend this model, then a concrete implementation will need to be created for the Projects REST API over the generated implementation.

Cannot create wikis on Gitlab, failed ECA check

See https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/34#note_4533 for more information

remote: fatal: unknown commit refs/heads/

I got this error today when I tried to push a branch in a new empty git repo:
https://gitlab.eclipse.org/eclipsefdn/memorials

This error did not stop the commit from being pushed to Gerrit

/--{[10200]chrisguindon@cg-newton:s004}----{~/localdev/memorials}--
| 15:01 <git:(main)> % git push origin main                                                                                                                                   2020-11-06
Enumerating objects: 4, done.
Counting objects: 100% (4/4), done.
Delta compression using up to 12 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 5.56 KiB | 2.78 MiB/s, done.
Total 4 (delta 0), reused 0 (delta 0)
remote: fatal: unknown commit refs/heads/
remote: Commit: _nil		~
remote: 
remote: 
remote: Warnings:
remote: 	A commit is required to validate
remote: Any warnings or errors noted above may indicate compliance issues with committer ECA requirements. More information may be found on https://www.eclipse.org/legal/ECA.php
remote: 
remote: 
remote: Errors or warnings were encountered while validating sign-off in current request for non-project repository.
remote: 
remote: Validation is currently not required for non-project repositories, continuing.
To gitlab.eclipse.org:eclipsefdn/memorials.git
 * [new branch]      main -> main

Add allowlist for emails beyond bot list

In migrating the GH ECA hook to use the service, it was discovered that all commits through the GH UI commit via a Github noreply email user. We should allow these commits rather than block the commit. We can treat these users as functionally bots in terms of current functionality and to ease the integration.

ECA check should (probably) not test "personal" or forked GitLab repositories

It does not block pushes, but shows potentially confusing errors like "The author is not a committer on the project.".

Double quotes break in commits JSON parsing

Double quotes in the body of a commit cause parsing failures in the Ruby pre-receive hook script file.

pre-receive hook declined
/opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/json-2.3.0/lib/json/common.rb:156:in `parse': 783: unexpected token at '{"author": {"name":"Stefano Puri","mail":"[email protected]"},"committer":{"name":"Stefano Puri","mail":"[email protected]"},"body":"Revert "initial extensions to support CONCERTO-FLA"  This reverts commit 0a1be2bfe130b98b9573e42359c5597bd4c9d77b. ","subject":"Revert "initial extensions to support CONCERTO-FLA"","hash":"bd302ecc574e29b7cfd64843c3c0c6bf19ea7944", "parents":["1ce0635ece0d3394204e9c5198487995e97e52bf"]} ' (MultiJson::ParseError)
	from /opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/json-2.3.0/lib/json/common.rb:156:in `parse'
	from /opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/multi_json-1.14.1/lib/multi_json/adapters/json_common.rb:14:in `load'
	from /opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/multi_json-1.14.1/lib/multi_json/adapter.rb:21:in `load'
	from /opt/gitlab/embedded/lib/ruby/gems/2.6.0/gems/multi_json-1.14.1/lib/multi_json.rb:122:in `load'
	from /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/eca.rb:52:in `block in <main>'
	from /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/eca.rb:44:in `each'
	from /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/eca.rb:44:in `<main>'

`gsub': invalid byte sequence in US-ASCII (ArgumentError)

A user is reporting an issue when trying to contribute code to GitLab.

More information is available here:
https://gitlab.eclipse.org/eclipsefdn/gitlab/-/issues/7#note_65