forgeflux-org/interface

API-space software forge federation

interface's Issues

Multi-commit PRs

Our current PR workflow looks like this:

1. Get patch at https://github.com/{owner}/{repo}/pull/{id}.patch
2. Process .fignore
3. Send to upstrea interface
4. Upstream interface applies patch and sends PR to upstream repo

If the PR was made up of multiple commits, we are losing valuable commit messages. I think we can accommodate multi-commit PRs by generating a sequence of patches for each commit of the PR.

Fix issue with the HOST variable during CI

As of right now, the GITEA_HOST variable in the .github/workflows/coverage.yml is hard coded into the file.
This has been done as there seems to be an error faced during the CI.

The current line should ideally be converted into,

DYNACONF_GITEA__HOST : ${{ secrets.DYNACONF_GITEA__HOST }}

[northstar] implement nodeinfo to fix insecure Interface registration

Hardcoded ports for interface auto-registration

With the merge of #86, we now have auto-registration working perfectly.
With one exception, the port is hardcoded to 8000 as of right now.

While this passes in development, it is imperative to load in the port from the configuration in production.

sqlite dates storage

Currently we are storing dates in string type since sqlite doesn't have support for a date datatype. This makes sorting a pain, so I recommend storing dates in unix timestamps

Expose admin use in forge implementation

Various forges might have different ways to identify a user(username, email ,etc). An interface should be made available to get the admin user's identifier so that hard coding admin user values like we are doing here:

interface/git.py
34:    def __init__(self, forge: Forge, admin_user: str, admin_email):
36:        self.admin = InterfaceAdmin(admin_email, admin_user)

interface/forges/base.py
30:    def __init__(self, host):  # self, base_url: str, admin_user: str, admin_email):

interface/forges/gitea.py
31:    def __init__(self):  # self, base_url: str, admin_user: str, admin_email):
➜  tmp.6358p3u9wv git:(master) rg GITEA.user
interface/forges/gitea.py
211:        path = format("/%s/%s" % CONFIG.GITEA.username, repo)
216:            "git@%s:%s/%s.git" % (self.host.netloc, CONFIG.GITEA.username, repo)

interface/runner.py
97:                if all([n["type"] == PULL, owner == CONFIG.GITEA.username]):

interface/git.py
88:    git = Git(forge, CONFIG.GITEA.username, CONFIG.SYSTEM.admin_email)

Possible Solution:

• interface/forges/base.py:

class Forge:
  def __init__(self, host, admin_user, admin_email):
    self.admin_user = admin_user
    self.admin_email = admin_email
  ...

• Forge implementation(Gitea):

class Gitea(Forge):
   def __init__(self):
       super().__init__(settings.GITEA.host, settings.GITEA.username, settings.SYSTEM.admin_email)

set user-agent to interface-controlled username

A bug in Interface might result in high traffic to the forge.

GitHub recommends developers to set user-agent to their username, that way if there's unusual traffic from them, GitHub admins will be able to identify it and sort it out.

test error

https://github.com/forgeflux-org/interface/runs/5122166495?check_suite_focus=true

[libgit] Repository lock impl is incomplete

interface/libgit/src/system.rs

Line 186 in 238bb0b

unimplemented!("When repo is locked")

Dynaconf deprecation warning

Set static var in settings module like the warning message advises

venv/lib/python3.9/site-packages/dynaconf/base.py:151
  /home/aravinth/code/forgedfed/interface/venv/lib/python3.9/site-packages/dynaconf/base.py:151: DeprecationWarning: Usage of `from dynaconf import settings` is now DEPRECATED in 3.0.0+. You are encouraged to change it to your own instance e.g: `settings = Dynaconf(*options)`
    warnings.warn(

Remove prefix in link fragments

This should be changed to /comment
https://github.com/forgefedv2/interface/blob/ac8a0bbb30e506f4c24032b023d5ee930cad49c5/interface/client.py#L30

On a broader note, I think we should categorize groups together. The reason why we are using constants as opposed to string literals is to make sure a route update is reflected everywhere it's referenced. I think if we create something like this(see below), it will get rid of the inconsistency introduced through _construct_url methods.

{
  "issue":
    {
      "create": "/api/v1/issue/create",
      "comment": "/api/v1/issue/comment"
      }
   }

---

Open API spec should be updated if changes are made #23