Also, should the migration guide & installation guide point users to the Github mirrors?
This might help avoid undue load on we.phorge.it?
I'll note that the Phabricator installation guide always pointed users to the Github mirrors as well.

FYI, the guide for migration doesn't seem to work quite smoothly for folks that were tracking the stable branch for Phabricator, because the new stable branch in Phorge does not have a linear changeset history to the old stable branch in Phabricator: if you follow the directions, you end up with a locally divergent stable branch that will contain a local merge commit.
Is there a reason the stable branch in Phorge wasn't created based upon the changeset history of the stable branch in Phabricator, in order to avoid this from happening?

I'll note that the developer-mode, timezone, serious-business and production-url config settings still use Phabricator in the names

The labs one was me from ages ago before a GH org name was decided on. IIRC the phorge org was already claimed and I just wanted to be squatting on something that could.be used down the road. Happy to delete / change ownership / whatever else

In T15046#2762, @jeremy.norris wrote:

In T15046#2761, @jeremy.norris wrote:

It appears there are not any public repositories yet, is this intentional?

Actually, what is the correct Github organization? In the description for this task, the link is to (which is where I initially looked and saw no public repositories):

https://github.com/phorgelabs

But then in the comments above, the link is to (which does appear to have public repositories that are empty?):

https://github.com/phorgeit

In T15046#2788, @MacFan4000 wrote:

@avivey I see that the repos currently access GitHub anonymously. For auto mirror to work you need to configure a valid credential. By this I mean you need to create a username/password passphrase credential with creds for a GitHub account that has write access to the GitHub repos, and set it in the diffusion uris.

@avivey I see that the repos currently access GitHub anonymously. For auto mirror to work you need to configure a valid credential. By this I mean you need to create a username/password passphrase credential with creds for a GitHub account that has write access to the GitHub repos, and set it in the diffusion uris.

In T15046#2762, @jeremy.norris wrote:

Well that didn't work: T15114: Can I create tasks?

I'll remove myself from trusted contributors just to test.

The form ( https://we.phorge.it/transactions/editengine/maniphest.task/edit/2/ ) needed a security policy. I think that should fix the problem?

https://secure.phabricator.com/book/phabricator/article/custom_fields/ custom fields allow you to set the required property in configuration. I'm not sure if you can use this to override a default built-in field but you could possibly replace the built in field with a custom field with same/similar name and type: users.

I would say the current create forms are fine, there should be 2 edit forms, 1 unrestricted one only visible to trusted users, and a restricted one that is only visible to non-trusted users (can be done with custom policy)

I’ll note that there is currently a restricted create form, for Trusted Contributors that allows anything to be changed.

In T15046#2761, @jeremy.norris wrote:

It appears there are not any public repositories yet, is this intentional?

It appears there are not any public repositories yet, is this intentional?

As @avivey mentioned, the GitHub organization is set up. Both Aviv and I have access, and I am willing to add other people in the core team.

We've created https://github.com/phorgeit and started configuring it to mirror the repos.

Process requires 2 forms with the following modifications:

• Create task form
  • Edit Form Configuration
    • Visible To -- All Users
  • Lock/Hide fields
    • Priority
    • Editable by
  • Change Default Values
    • Editable by -- Custom (likely Administrators & other trusted projects)
• Edit task form
  • Visible to certain subset of users (like a project)

From reading the git code, looks like there is a flag to allow this feature - uploadpack.allowReachableSHA1InWant, though I'll need to check that it actually works.

The specific set of commands im looking at are

mkdir -p phabricator_git_repo && cd phabricator_git_repo && git init && git remote add origin https://we.phorge.it/source/phorge.git && git fetch origin b11c6fcacd8bceafc2a2f223037952dc817f4d7f && git reset --hard FETCH_HEAD && rm -rf .git && true

this commit does exist https://we.phorge.it/rPb11c6fcacd8bceafc2a2f223037952dc817f4d7f
we use a build system which fetches the code from a git repo and makes it available to the next stage of the build

From a quick googling, it looks like this isn't a server configuration, but most likely the commit you're looking for just isn't in the remote.
Why are you using this command? Are you using submodules for deployment?

I mean, that's not a particularly good solution to the problem. It just makes the time for which it appears to be fixed longer (even though nothing has changed)

I would suggest increasing the TTL to a day if you are not planning on moving servers in the near future.

@avivey the one in upstream does not contain the new ISRG Root X2 CA.

I submitted D25049 for review on the 26th to address certs signed by the ISRG Root X2 root that is in the updated default.pem file.

If you view a book, then view source and search for PHID-BOOK then you should find a policy link. That's the PHID of the book you're viewing.

We've picked up an updated version of the pem at https://secure.phabricator.com/D21739 - it's not the latest, but is it recent enough?

I've written https://we.phorge.it/w/installation_and_setup/update_from_phabricator/, and I think it's basically ready for simple case (and considering we're still compatible with Phabricator in all technical aspects).

I think we're done here too? E13.

I've cowboy-merged this last week. Not sure why all these commits decided they are part of this task though?

I've tried locally with ./bin/remove , and it appears to work. To get the phid, I've visited the page and used "Actions -> Advanced -> View Handle" - I don't have this action available here.

Phorge is not yet ready. See T15014, T15023, T15026.

In T15012#2678, @avivey wrote:

I've re-generated the docs, and now we have two copies:

so:

1. need to delete the old ones, I didn't find a straight-forward way to do that
2. maybe do some http redirect from the old links to the new ones.

@avivey Thanks a lot for the hints. I will take a look at the Spaces. That sounds like it could be helpful for our purposes.
@rraval Could you or someone else verify that a project that is made visible only to Administrators still shows up when a user opens the search selection list on the Subscribers field? And is this considered to be a bug or a feature? Of course i can set up a new Task for this if that makes sense.

I've started the a draft for the Going Public announcement - {Blog Post: Going Public} - please chime in with comments...

Note the ISRG Root X2 has been added here used by Lets Encrypt.

In T15012#2679, @MacFan4000 wrote:

We should also generate the arcanist docs.

We should also generate the arcanist docs.

I've re-generated the docs, and now we have two copies:

(Regarding the original task description:)

In T15110#2655, @avivey wrote:

I'll try to force the GC to run, maybe this will delete them.

But still it is worrisome that we can configure visibility only by Administrators, yet everybody can assign the project as subscriber... Maybe that is a bug ?

@rraval Right, i overlooked this setting. I managed to hide most projects from the Subscribers Search panel. We also have reduced the number of Projects to keep things more tidy.

@Higgs You should be able to Project → Edit Details → Visible To → Project Members. Does that do what you expect?

I'll try to force the GC to run, maybe this will delete them.

We use Projects for grouping users into teams. But unfortunately every user can see all Projects and assign them as subscribers to Tasks, regardless if they are members or not. Normally (in our case) Tasks are only relevant for users in the same project. Having the other projects displayed in the subscribers selection is unfortunate in this case.

Somewhat related - see T15050