Skip to content
This repository has been archived by the owner on Nov 18, 2021. It is now read-only.

"Create New File" URLs with "filename" query string parameters don't seem to work quite right #1527

Open
airbreather opened this issue Mar 20, 2019 · 6 comments
Labels
automation Reducing manual interactions and increasing productivity through automated processes bug documentation file-view ui

Comments

@airbreather
Copy link

airbreather commented Mar 20, 2019

What the GUI exposes

When browsing the source code in a repository, GitHub offers a button that says "Create New File":
image

Clicking on it brings the user to a page that looks something like this:
image

The specific link is as follows:

https://github.com/NetTopologySuite/NetTopologySuite/new/develop/NetTopologySuite

What we found

The dotnet/docfx developers discovered that you can use query string parameters to pre-fill some of the values for you.

  • This allows that project to give end users a link that will let them overwrite the auto-generated documentation and/or add more information that isn't in the code, by creating files in an "overwrite" folder with the machine-readable name and initial contents so that the tool will be able to see that on the next run and incorporate it into the documentation site.

Specifically, the value query string parameter fills the main text box, and the filename query string parameter can be used to fill in the filename.

Issues

The value parameter seems to work just fine, but there are some issues with filename.

Goes up a level

When filename is specified at all, the last folder part of the URL seems to be ignored. Compare the following URL to the URL from above:

https://github.com/NetTopologySuite/NetTopologySuite/new/develop/NetTopologySuite?filename=Callees.cs&value=public+static+class+Callees%0A%7B%0A++++public+const+string+PrimaryCallee+=+%22Ghostbusters%22%3B%0A%7D

It takes you to a page that looks like this (compare the folder path to what we had above):
image

Workaround 1 breaks "cancel" link

The DocFX folks also saw this, but they found a workaround: append some dummy path after it like "new", so that it puts you into the same folder.

Compare this URL:

https://github.com/NetTopologySuite/NetTopologySuite/new/develop/NetTopologySuite/new?filename=Callees.cs&value=public+static+class+Callees%0A%7B%0A++++public+const+string+PrimaryCallee+=+%22Ghostbusters%22%3B%0A%7D

That brings us here:
image

However, clicking the encircled "cancel" link takes us to a nonexistent page. See discussion and other details in dotnet/docfx#3156:

https://github.com/NetTopologySuite/NetTopologySuite/tree/develop/NetTopologySuite/new

image

Workaround 2 doesn't stick through "cancel" and "back button"

So I had the idea that, instead of appending some dummy that doesn't exist, we could try duplicating the last folder in the filename query string parameter:

https://github.com/NetTopologySuite/NetTopologySuite/new/develop/NetTopologySuite?filename=NetTopologySuite/Callees.cs&value=public+static+class+Callees%0A%7B%0A++++public+const+string+PrimaryCallee+=+%22Ghostbusters%22%3B%0A%7D

That brought me here, and it seemed perfect!
image

"Cancel" worked just fine, bringing me back to the folder that would have contained the file. Then I clicked on my browser's "Back" button (Firefox 65), and:
image

...darn. It seems to have ignored the path information from the filename parameter for some reason.

What we really need

What we need is a supported way to pre-fill some of the information on the "Create New File" page in order to be able to help users contribute incremental, targeted improvements to documentation that can be consumed by a tool.

@airbreather
Copy link
Author

I've sent an e-mail to GitHub support about a minute ago linking to this thread.

@TPS TPS added bug ui file-view documentation automation Reducing manual interactions and increasing productivity through automated processes labels Mar 21, 2019
@airbreather
Copy link
Author

E-mail reply:


GitHub Staff (GitHub Developer Support)
Mar 26, 11:08 AM UTC

Hey Joe,

Thanks for reaching out!

We'll pass your request onto the team to consider.

I can't promise if or when we'd add full support for pre-filled new file creation parameters but we'll make sure the request is in the right hands.

Cheers
GitHub Support

@llwt
Copy link

llwt commented Apr 21, 2020

One way around I I just stumbled across that seems to work is to put the whole path into ?filename and remove the base:

https://github.com/NetTopologySuite/NetTopologySuite/new/develop?filename=NetTopologySuite/Callees.cs&value=public+static+class+Callees%0A{%0A++++public+const+string+PrimaryCallee+=+%22Ghostbusters%22%3B%0A}

pipecd-bot pushed a commit to pipe-cd/pipecd that referenced this issue Aug 17, 2020
**What this PR does / why we need it**:
Each deployment config template comes with a file creation URL, which is for creating a new file under the git path, with template content as default value. Something like:
https://github.com/pipe-cd/debug/new/master/kubernetes/analysis-by-metrics?filename=.pipe.yaml&value=%23+This+configures+a+non-progressive+delivery.%0AapiVersion%3A+pipecd.dev%2Fv1beta1%0Akind%3A+KubernetesApp%0Aspec%3A%0A++input%3A%0A++++manifests%3A%0A++++++-+deployment.yaml%0A++++++-+service.yaml%0A++++kubectlVersion%3A+2.1.1

Whereas, I'm getting an issue about specifying filename: isaacs/github#1527. I'll be glad to address it later.

**Which issue(s) this PR fixes**:

Fixes #627

**Does this PR introduce a user-facing change?**:
<!--
If no, just write "NONE" in the release-note block below.
-->
```release-note
NONE
```

This PR was merged by Kapetanios.
pipecd-bot pushed a commit to pipe-cd/pipecd that referenced this issue Aug 17, 2020
**What this PR does / why we need it**:
We're getting an issue with specifying a filename: isaacs/github#1527
In short, the last path part of the URL is ignored when specifying a filename. For now, appending dummy path as a workaround.

**Which issue(s) this PR fixes**:

Fixes #

**Does this PR introduce a user-facing change?**:
<!--
If no, just write "NONE" in the release-note block below.
-->
```release-note
NONE
```

This PR was merged by Kapetanios.
@airbreather
Copy link
Author

Not sure when this was updated, but re-testing Workaround 1 now, Cancel doesn't go to a 404 anymore.

The workaround is good enough for me, but (perhaps) not for others, and I don't have any official documentation indicating that this is supported, so AFAIK it could break again, so I'll leave this open.

If someone can link to official documentation that shows how to do the "What we really need" part of the initial issue description, I'll be happy to close this.

@airbreather
Copy link
Author

airbreather commented Oct 2, 2020

One way around I I just stumbled across that seems to work is to put the whole path into ?filename and remove the base:

That's essentially Workaround 2 and has the same "Cancel --> browser Back button" problem on my machine.

@coolaj86
Copy link

coolaj86 commented Jul 26, 2021

Has anyone figured out a method like this for gist.github.com?

Update from Github Team member: https://twitter.com/JasonEtco/status/1419703200450588685
(it may come down the pike soon)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
automation Reducing manual interactions and increasing productivity through automated processes bug documentation file-view ui
Projects
None yet
Development

No branches or pull requests

4 participants