Page MenuHomeSolus

Automatic Transit of Locally Built Packages to Local Repo
Closed, LockedPublic

Description

Linting...
No lint engine configured for this project.
Running unit tests...
No unit test engine is configured for this project.
 Exception 
ERR-CONDUIT-CORE: Validation errors:
  - Creation of this diff was rejected by Herald rule H9.
  Rule: Uploading eopkg files is bad.
Reason: Do not upload eopkgs.
(Run with `--trace` for a full exception trace.)
[2020-03-13 10:49:58] EXCEPTION: (ConduitClientException) ERR-CONDUIT-CORE: Validation errors:
  - Creation of this diff was rejected by Herald rule H9.
  Rule: Uploading eopkg files is bad.
Reason: Do not upload eopkgs. at [<phutil>/src/conduit/ConduitFuture.php:62]
arcanist(), phutil()
  #0 ConduitFuture::didReceiveResult(array) called at [<phutil>/src/future/FutureProxy.php:58]
  #1 FutureProxy::getResult() called at [<phutil>/src/future/FutureProxy.php:35]
  #2 FutureProxy::resolve() called at [<phutil>/src/conduit/ConduitClient.php:64]
  #3 ConduitClient::callMethodSynchronous(string, array) called at [<arcanist>/src/workflow/ArcanistDiffWorkflow.php:518]
  #4 ArcanistDiffWorkflow::run() called at [<arcanist>/scripts/arcanist.php:394]

Long story short - I haven't uploaded any eopkg files. I'll manually attach the patch I'm trying to send.

Event Timeline

ikeycode renamed this task from Herald rule H9 broken to Herald rule H9 partially broken.Mar 13 2020, 12:42 PM
ikeycode assigned this task to JoshStrobl.

The rule is working exactly as intended. It doesn't allow upload of any eopkg files, or files containing the word eopkg, as this should never be a requisite for a package-related patch.

As far as common is concerned, that's really only something the #core_team_org have been modifying and maintaining, and in those cases H9 is bypassed.

Regarding wanting to transit the eopkg files to the local repository, I would much rather that functionality be delegated to solbuild itself as it's not uncommon for folks using local repositories with solbuild to move the target location. When ypkg3 is finished there will be no explicit need for .eopkg files to be present in the working directory for ABI report generation as that will be built in.

Therefore, I would propose:

  • Teaching solbuild to automatic transit of packages to the configured local repo directory.
  • Rolling ABI report functionality into ypkg3 as planned.
  • Ensuring that make local results in an automatic transit of packages.
DataDrake renamed this task from Herald rule H9 partially broken to Automatic Transit of Locally Built Packages to Local Repo.Mar 18 2020, 3:45 PM
DataDrake triaged this task as Normal priority.
ikeycode added a comment.EditedMar 18 2020, 6:16 PM

OK, but its not working as intended at all. Mentioning eopkg in a package patch does and has happened (I literally am the voice of experience here.)
The rule is clearly too crude. As for solbuild having the functionality I don't directly object, but the entire process needs review tbqh.

Chiefly package repository priorities need to work correctly in mixed and layered repositories through a well designed system, something that eopkg currently lacks.
Given the amount of engineering effort required to make this nice in solbuild, and the obvious limitations in eopkg it would work around, the ROI is practically nil compared
to integrating directly with the Makefile system (which could do with overhauling)

Unless eopkg is looking at upgrades any time soon, I see no problem in pursuing the original Makefile(or Makefile alt) approach

DataDrake added a comment.EditedMar 18 2020, 6:49 PM

Let me be perfectly clear. This is a very low priority issue that you are making sound far worse than it actually is. That rule is working exactly as Josh intended when it was implemented. If something truly needs to be patched with regard to having the word eopkg in it, I can 99% guarantee that it's a patch that should probably be applied to an upstream repository and not one hosted on Phab.

I have presented you with the approach that I believe will be the most flexible and least obtrusive to existing workflows. No one is saying that you can't add your own custom Make rule in the meantime to suit your purposes. However, I will not accept that patch to the Makefile system because it will only work for the default local repository directory and completely ignores user-specified configuration of solbuild. As an advocate of stateless configuration, I'm sure you can understand that.

ypkg already supports having a different output directory. solbuild already supports having a local repository. The only barrier to implementing this functionality in solbuild is the current limitation of the Makefile system where ABI reports are generated after solbuild exits. ypkg3 will generate ABI reports separately and I will be sure to split the output directories for metadata files and package archives so that this is a non-issue.

I wrote a large post of a reply but I've deleted it. Instead I'm just going to say this.

Good luck.

ikeycode closed this task as Invalid.Mar 18 2020, 11:08 PM
This comment was removed by DataDrake.

@serebit No need to draw this out.

DataDrake changed the task status from Invalid to Locked.Mar 19 2020, 12:39 AM
This task has been locked.