For the development environment this would probably be best in a diviner book/document instead of a wiki.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jun 22 2021
Jun 20 2021
One thing to consider are installs where the database is being queried outside of Phabricator - anyone doing data analytics or other tooling that interacts with the database directly would be affected by this change. I’m not suggesting we never consider it but it would be better if we can provide tooling/scripts where possible or even create a wider time span for migration. Would MySQL/MariaDB support aliases of some sort? Or maybe there’s a way we can support both namespaces for a time
Jun 19 2021
I created Release Process in our internals wiki to start the documentation on what the release process would look like, based on some of those commented. As we flesh out the plan I’d like to update that.
Abandoning for D25006
Wouldn’t the owners package only cause revisions to be marked, but wouldn’t that leave non-revision commits t not be handled? The herald rules act upon incoming commits rather than ensuring every revision is reviewed.
I updated the herald rules to use O1 so it should work fine next time
Hmm try with this? There are some nuances I think to work out with the herald rule
In D25002#160, @deadalnix wrote:As an asside, you might want to split up the logo rename part of that diff in another diff, this should be able to get in eight away, and there is no reason to wait on a resolution for the translation business to move on with it.
Still need to search for instances of Phabricator appearing anywhere within quotes. Testing all this will be fun.
- Revert the logo and favicon (but keep logo rename)
- Added PhabricatorApplication::PROJECT_APPLICATION_NAME to default to Phabricator
- Updated instances of 'Phabricator' to use the new constant instead
Updating comment per discussion
Currently rP and rARC only allow Blessed Committers to push - with those herald rules in place should we open that up? Maybe we should have a separate group "Contributors" for anyone who wants to submit revisions for approval? Or should it be opened to any user?
One thing that I think distinguishes these changes from T15006: Re-brand Phorge is that those changes are mostly intended to be submitted upstream in the hopes Phabricator accepts changes which enable more-easily re-branding the project. For Diviner I don't think that's something we can do since I'm guessing all the book content is effectively static.
Oh, excellent! Thanks for looking into that.
Since we're planning to eventually host more-open/accessible community repositories I created these as separate object rules instead of as a global rule
I created H7 Guard Phorge Repo with Blessed Committers and H8 Guard Arcanist Repo with Blessed Committers to guard rP and rARC
It looks like Diviner was used to generate documentation however a lot of the documentation still refers to "Phabricator". We'll probably want a separate task just for reviewing and updating all the documentation to make sure it's appropriate.
@Ekubischta it looks like @chris added you - could you verify your email? I'm also thinking anyone in the "security" or "blessed" groups should turn on MFA as well.
In D25004#131, @tobiaswiese wrote:I have some concerns regarding the new comment, as these files don't really belong to aphlict, but are npm npm artifcats. If node-ws is installed via e.g. the system package manager (which is probably the better idea anyway), these files/folders won't be created.
Jun 18 2021
I created T15013: Better handling of node/npm installation for Aphlict for further discussion
Yea it probably won’t have an effect until they run npm install/ci. We could create those files and include. I’ll update
I was thinking about having it version controlled and I do think that would be a good idea at some point. If we do that now I think that might mess up installations which happen to be running different versions of ws, or the upgrade path would require some additional steps. I think it would be something like
- Run npm uninstall
- Delete package-lock.json
- Upgrade
- Run npm ci which should follow the package-lock.json definitions
Update comment
Ah I wasn't aware of that option. I created D25004: Update .gitignore to account for package-lock.json if we want to update the .gitignore
In T15011#386, @Ekubischta wrote:A few things @willson556
- Untracked file in phorge source support/aphlict/server/package-lock.json
This and D25001: T15006: Update .arcconfig to point to we.phorge.it are duplicates. I tried to land it this morning but ran into issues with the land process that I didn't have time to work out
We should consider a Vagrantfile in place of docker containers. I think it will be more approachable to newcomers having a single VM with all the services/configurations setup compared to managing multiple containers.
I think the plan for this is going to be
- Try to address all external-facing "Phabricator"s
- Submit this patch upstream on secure.phabricator.com
- Phorge pulls in this change from upstream
Renaming getDefaultProjectName() to getDefaultWordmark()
Infrastructure setup is being documented in server
Okay I think everything is setup for the migration to we.phorge.it
- I added a port 80 configuration for we.phorge.it to nginx
- I ran certbot to grab a cert for we.phorge.it, I used --nginx
- I updated the nginx conf file to clean up the automatic modifications and setup secure.phorge.it and secure.phorge.dev to redirect to we.phorge.it
- I updated phabricator.base-uri to use we.phorge.it
- I updated notification.servers to use we.phorge.it
- I restarted nginx
Okay I'm going to try swapping out the URL for we.phorge.it. If everything goes well everyone will need to update their URLs and clone repos. If things don't go well I'll, uh, glue it back together
Notifications are also functional. Took me a minute to remember where the "test notification" feature is located (it's in your user settings > notifications)
Whoops, commented on the wrong task, tested imagemagick in T15006#314
I'm going to get aphlict up and running before looking at changing the domain name stuff. Not having notifications is kind of a bummer.
Jun 17 2021
(I verified by starting a new ssh session over port 2222 and freshly cloning phorge after modifying diffusion.ssh-port)
The ports are switched
- Administrative port is now 2222
- VCS port is now 22
@chris I'm looking to make the SSH configuration change shortly, having the administrative ssh go over port 2222 and vcs go over port 222. In the event everything goes horribly wrong does someone have physical access to this machine or some other control mechanism?
For the time being I've modified the wordmark configuration to manually upload the logo file https://secure.phorge.it/config/edit/ui.logo/
@avivey the current installation includes a commit I had made on the github fork which made minimal changes to rebranding. Ultimately I think we'll want to scrap that commit but it should have replaced the eye icon with a lovely heart.
- move administrative SSH to port 2222
This one is going to require that everyone who currently has a cloned repo to update it, correct? I'll take a look later tonight at swapping this out, as the sooner the better IMO. I'll comment here before making the change.
I created Release Process for the release process.
In T15000#289, @avivey wrote:https://secure.phabricator.com/book/phabricator/article/diffusion_hosting/
I think /var/repo should be owned by git:
The user the daemons run as. We'll call this daemon-user. This user is the only user which will interact with the repositories directly. Other accounts will sudo to this account in order to perform repository operations.
Do we have a documented release strategy? I'm not very familiar with git and I only have a vague sense of what Phabricator's release process was. I think it's something like
- Accepted changes are landed into master
- Evan cherry-picks changes from master into stable to "release"
Possibly with some additional smoke-testing somewhere in all this?
I think there might be some permissions issues with the log location but I'm not sure if it's the root cause of the issue being seen here.
Jun 15 2021
Just copying my thoughts I wrote from the zulip
IMO our landing page needs to have a summary of our vision statement or something similar that explains what this is and where it’s going, along with screenshots and links to documentation on how to install/configure.
Personally I would prefer having a separate landing page that is primarily static content as I do believe it lends to easier intro of a product (along with some credibility) - however those things are primarily to increase adoption which is not one of our current goals as well it does add overhead and isn’t critical - I wouldn’t mind holding off on that for a while. Phacility’s main website was effectively the landing page for Phabricator. I don’t think it’s still around for reference but it had most of what I described.
I do think we should consider a separate landing page as prerequisite to announcing the product on other websites. Maybe it’s not a strong enough argument but if we’re announcing in other sites then we are probably trying to increase adoption or build the community.
Jun 14 2021
I don’t think it has really started yet. I had some changes on GitHub which I’ve abandoned but I think those changes were copied into the install here.
Jun 13 2021
Jun 11 2021
When changes are made please document what all they end up being.
On the topic of increasing community involvement we will also want to produce documentation for setting up development environments as well as the steps to submit changes upstream (like a quality checklist). To make development environments even easier we might want to consider supporting something like a vagrantfile so people can get started with very few steps.