Prepare for rename to setup-beam

[starbelly]

After the setup erlang PR is merged (which I'm not linking to as I don't want it to close this issue) we need to do a PR to change instances of setup-elixir to setup-beam, this should be the limit of the scope. Once this is merged in, we can rename the repo.

@wojtekmach had previously tested if checking the name of repo and/or action effects usage of existing releases and it seems no, it should be fine. Though, we should surely double check this and do whatever we can do ensure this is the case prior.

If all this is good, then we can publish setup-beam@v1, once again operating under the assumption that setup-elixir@v1 will continue to work as is.

[paulo-ferraz-oliveira]

Do you know, if @v1 represents @v1.x or do we have to keep moving the tag up?

[starbelly]

@paulo-ferraz-oliveira I would assume it does, but research required.

[paulo-ferraz-oliveira]

I'm asking especially since, at the moment, v1 and v1.6.0 are the same commit.

[starbelly]

@paulo-ferraz-oliveira I think what we'll have to do is

• fork this
• publish as setup-elixir under the name space of the fork as v1 (v1.6)
• rename it
• publish as setup-beam under the name of the fork as v1 (v1.7)
• observe
• delete the fork and published actions

[paulo-ferraz-oliveira]

Yeah, sorry, it was a sidetracking question[1]. I agree with your plan, though.

---

[1] Still am unable to understand how @v1 is kept (@ericmj, is this tag manually moved?).

[starbelly]

@paulo-ferraz-oliveira the way it works is you make a tag such as 1.6.0, you then reset v1 tag to the head of the new tag.

[ericmj]

I think what we'll have to do is [...]

Why do we need to do anything other than renaming?

Still am unable to understand how @v1 is kept (@ericmj, is this tag manually moved?).

Yes.

[ericmj]

Do we know if GitHub will keep the redirect forever from setup-elixir to setup-beam? If not, for how long will they redirect and what's the migration plan for users to the new action name?

[starbelly]

Why do we need to do anything other than renaming?

Theoretically, that should be fine if you mean just rename the repo and publish a new 1.x version, but I just thought we might want to be doubly sure we don't mess up builds.

Do we know if GitHub will keep the redirect forever from setup-elixir to setup-beam? If not, for how long will they redirect and what's the migration plan for users to the new action name?

https://github.bokerqi.topmunity/t/how-long-does-github-forward-renamed-moved-repos/582

@ericmj TL;DR is indefinitely.

[ericmj]

Theoretically, that should be fine if you mean just rename the repo and publish a new 1.x version, but I just thought we might want to be doubly sure we don't mess up builds.

What name are we going to use for the fork?

[wojtekmach]

Im not sure a fork is necessary, I'd rename the repo to setup-beam, test it with another project, and in an very unlikely case it doesn't work, rename it back. After a day or two, make an announcement that setup-beam is the new repo.

[starbelly]

What name are we going to use for the fork?

@ericmj I would suggest something obscure, and not actually setup-elxir, especially for the publish

Im not sure a fork is necessary, I'd rename the repo to setup-beam, test it with another project, and in an very unlikely case it doesn't work, rename it back. After a day or two, make an announcement that setup-beam is the new repo.

Maybe, but I don't know, production is always the real test. I'd rather be extra sure with a small investment (i.e., fork, publish, rename, publish) than to break a bunch of builds and deal with an onslaught of issues and slack messages. But to your point, maybe I'm overly concerned here.. but yeah, being sure is no bad thing especially at a cheap cost.

[ericmj]

If the rename doesn't work the fork won't help since it's using a different name and if it doesn't work we can just rename it back. Or what am I missing?

[starbelly]

If the rename doesn't work the fork won't help since it's using a different name and if it doesn't work we can just rename it back. Or what am I missing?

Hmm what I'm suggesting is not doing the rename until after fork test is done, does that clarify?

[ericmj]

Hmm what I'm suggesting is not doing the rename until after fork test is done, does that clarify?

What are we testing with the fork?