Installing NPM package using tags that include slashes about actions HOT 10 CLOSED

It sounds like we need to escape slashes. Given a branch named mk/something-what we could convert it into the npm tagmk__something-what

We just have to make sure that on the cleanup step, we take mk__something-what and check for a git branch named mk/something-what

from actions.

@cowboyd Got the prototype working. We have a save argument that allows people to specify which tags to persist. Should we expect them to input mk_something (npm tag) or mk/something (branch)? It checks against branch so if they input npm tag, we can undo the / escape before checking.

from actions.

@cowboyd Not sure if it helps but I made a diagram to visualize the dilemma.

Edit: okay so visualizing it helped me. I think the safest way would be to mask (not sure if that's the right verb) user input and github branches.

Because if someone has a branch called mk/a_b, the tag of that will be published to NPM as mk_a_b. Any attempts of unmasking will result in mk/a/b.

So the diagram is incorrect and in on delete we should be applying the same mask to github branches and checking it against npm tags (untouched).

from actions.

I believe the terminology that you're looking for is "encoding" and "decoding", and yes we'll have to do that. The trick is that your encode/decode function pair needs to be an isomorphism: decode(encode(x)) = x

If you have as part of your encoding an escape character, then you also need to encode your escape character.Let's say that we encode / as _, Then it means we need to also encode _ as __

And on decode, we recognize that __ -> _ and _ -> /

from actions.

So in the example:

gitbranch2npmtag("mk/ab") //> mk_ab
gitbranch2npmtag("mk/a/b") //> mk_a_b
gitbranch2npmtag("mk/a_b") //> mk_a__b
gitbranch2npmtag("mk/a__b") //> mk_a____b

Long story short is that git branches with _ in them make ugly npm tags, but that just means we should avoid them.

from actions.

@cowboyd
Do we need _ to turn into __? Since we're only dealing with the branch name, I was thinking we could just turn / into _ and nothing else. So the "life cycle" of these branch tags would look something like this:

function encode(tag) {
  return "$(echo $tag | sed 's/\//\_/g')";
}

on PR:

npm publish --tag $(encode(branch-name-of-head-ref))

on Delete:

for tag in $all-npm-tags // $tag is already encoded because it's coming from npm
  if 
    [ $tag = latest ] ||
    [ encode($keep-argument-from-workflow) | grep -e $tag ] ||
    [ encode($branches-from-github) | grep -e $tag]
      then
        keep $tag
  else
    remove $tag from npm
done

Avoiding the need to decode and just encoding whenever we're dealing with npm tags seems like it would be the safest approach?

Edit: And also this would mean the users can input the tags they want to preserve in whichever format they want. mk_yeah_branch and mk/yeah/branch would both work.

Experimented on minkimcello/georgia.

from actions.

The case I'm trying to avoid is:

1. Let's say we have a git branch called mk_foo
2. We create an npm tag mk_foo
3. branch is deleted.
4. We download the tag mk_foo from npm, and want to find out what branch to delete
5. We look for a git branch mk/foo but it doesn't exist, so we don't delete it.

from actions.

Do we need _ to turn into __

Yes.

Stated another way: If I have two branches, mk/foo and mk_foo, they will resolve to the same npm tag, so when they are pushed to their respective PRs, they'll overwrite each other. By the same token, removing one branch will remove the shared tag.

Your strategy of only writing an encoding function will work though. It's just the encoding that needs to be unique. mk/foo and mk_foo must encode to different tags.

from actions.

1. Let's say we have a git branch called `mk_foo`
2. We create an npm tag `mk_foo`
3. branch is deleted.
4. We download the tag `mk_foo` from npm, and want to find out what branch to delete
5. We look for a git branch `mk/foo` but it doesn't exist, so we don't delete it

In step 4, we're using branches to see which tags to delete and not the other way around.
In step 5, we delete the tags of branches we can't find. So if we were to decode mk_foo tag to mk/foo and can't find it, mk_foo npm tag would be deleted (which would be the results we want but not with the correct method). But because we're not decoding in this case, we'd be looking for branch mk_foo which also won't exist so it would be removed for the right reasons... right?

Stated another way: If I have two branches, mk/foo and mk_foo, they will resolve to the same npm tag, so when they are pushed to their respective PRs, they'll overwrite each other.

I was just thinking this too. I'll have the actions replace _ with __. We don't have to worry about someone having a branch with __, right? That'd be one very ugly branch name and maybe they deserve an error code at that point.

By the same token, removing one branch will remove the shared tag.

Wouldn't removing one branch result in the unintended behaviour of sustaining that shared tag because the other branch that wasn't deleted would trigger the filter?

from actions.

We don't have to worry about someone having a branch with __, right?

We should handle the case, it's easier than not handling it, and who knows maybe there will be some justification we don't know about?

The encoding for a branch with _ would be __ and a branch with __ would be ____ and so on. It's not great, but the very fact that they are ugly is their own disincentive to use them.

from actions.