It should be possible to do a pull request from inside GT

[svenvc]

External (non-feenk) developers should be able to contribute to GT through the industry standard GitHub process of pull requests.

Since the released image does not contain repositories, the necessary repository has to be recreated.

Next a fork must be created.

Then a feature branch must be added on which to commit/push changes.

Finally a pull request must be submitted.

The GitHub CLI tool gh can be used here.

[svenvc]

There is now a first draft of a proof of concept of this process

https://book.gtoolkit.com/contributing-to-gt-through-a-github-pull-r-7gkxhsrfoc11i8k03v35q7fhb

[svenvc]

Here are some additional screenshots to illustrate the Contribute/PR story. Both terminal screenshots show what should work before you try the process.

Create a private repository in your GitHub account, add some file to it, and make sure you can clone using the 2 URL variants, without a need for any authentication. Then start GT in that terminal.

After you commit and push on your feature branch in your fork, the GT git tool should look like this.

Using the GitHub web UI you can verify that your fork has the commit in the feature branch.

After you create the pull request (either scripted from GT or using the GitHub web UI), the PR should appear in the upstream repository.

[svenvc]

By using the new GtGitHubAPITool instead of GtGitHubCLITool (one external dependency less) and some newly added actions, the following flow/process is now possible.

Make sure the GitHub Personal Access Token is set.

Then either fork/clone/load/register from GtGitRepositoryRegistryHistory

Or fork an existing repository in place and clone/load/register it.

Create a new feature branch.

Make a change to an existing method.

The repository is on the feature branch and sees the change.

Commit the modification/change.

Push it on our fork/branch.

Finally create the pull request.

Which should return a pull request JSON with a URL.

[seandenigris]

This is really cool!

And... I continue to be wary of storing credentials in a Smalltalk image. There is no way to reliably prevent them from being saved to disk unencrypted with the image. At least with the cli approach one can use ssh-agent with a password protected SSH key.

[botwhytho]

This is really cool!

And... I continue to be wary of storing credentials in a Smalltalk image. There is no way to reliably prevent them from being saved to disk unencrypted with the image. At least with the cli approach one can use ssh-agent with a password protected SSH key.

I expressed same feedback in Discord thread before this was closed, please look at this message as it may be addressed.

[seandenigris]

The problem is that even if it's always read from a file, even temporary objects that haven't been garbage collected can be saved to disk during image save. AFAICT there is no way to secure secrets in a Pharo-based image other than using a read-only image.

[svenvc]

All true.

But security is never absolute, it sits on scale, different people or environments might have different requirements.

It is important to be aware of the risks and to offer some options.

The way I see it: if it lives in a file on disk it is not different from living inside a saved image, that is all on my own machine. As long as I am aware of not sharing the image with someone unless I clear the secret.

It is all good and well to try keep secrets out, but you need them to access remote systems, so eventually they need to be passed around.