Prepare for rename to setup-beam #20
Comments
|
Do you know, if |
|
@paulo-ferraz-oliveira I would assume it does, but research required. |
|
I'm asking especially since, at the moment, |
|
@paulo-ferraz-oliveira I think what we'll have to do is
|
|
Yeah, sorry, it was a sidetracking question[1]. I agree with your plan, though. [1] Still am unable to understand how |
|
@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. |
|
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? |
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.
https://git.luolix.topmunity/t/how-long-does-github-forward-renamed-moved-repos/582 @ericmj TL;DR is indefinitely. |
What name are we going to use for the fork? |
|
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. |
@ericmj I would suggest something obscure, and not actually setup-elxir, especially for the publish
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. |
|
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? |
What are we testing with the fork? |
After the a new repo is made with the contents of this repo and named something like All that said, if this is clearly documented some where in github that this should just work and we don't need to test it to be sure, then maybe not needed, but I saw no such documentation when I looked before and I myself just rather be sure. Like I said, the cost of doing so is just about nil, so I don't see why not. |
I believe @wojtekmach already tested this and confirmed it to work. But nothing is blocking testing it again now so go ahead, we don't need to wait for anything to do a rename test on a separate repo. |
|
yeah I've already performed a test like that but as they say: if you want something done right, do it yourself :) |
|
@wojtekmach I didn't think you tried publishing? That's my focus is on. Publish, use, rename, publish again, use. But maybe you did? |
|
There isn't really a publish process for actions, we just use a git reference which normally is a tag. So if it works with one tag it should work with all, regardless of when it was created. Also note that the rename is not blocked by the PR #9 being merged. In fact, we should wait a while with publishing v1.7 after merging so we can test the main branch on our own repos before publishing. |
|
@ericmj That makes sense. I of course trust @wojtekmach too. I thought there was something "special" a "button" click :) With that said, you ready to rename then? |
|
this is the test: wojtekmach/setup-elixir-bug@5158312. I've renamed wojtekmach/beamup2 to wojtekmach/beamup and that workflow continued to work after the rename. |
We should have a PR ready with changes to the README and other places that references the name. Personally I would wait until the work week with doing the rename in case any support or quick fixes are needed, but that's up to you of course. |
|
@ericmj hmm yeah, let me do that real quick. |
|
@paulo-ferraz-oliveira You'll have a few merge conflicts to deal with, hate that the cookie crumbles that way, but @ericmj is right, this should happen first. |
Hmm you would wait until say Tuesday? Rationale being better to blow up in the week vs a big surprise on monday? |
Ahh n/m your concern is about doing work on the weekend. Yeah, that makes sense. |
|
Merge conflicts do not present an issue, at this moment. Your changes are very small in comparison to #9. |
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20
See erlef/setup-beam#20 We also bump to latest OTP 25.
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20
Remove extra redirection. See erlef/setup-beam#20. Also added GHA badge to readme.
Remove extra redirection. See erlef/setup-beam#20.
Remove extra redirection. See erlef/setup-beam#20.
Remove the extra redirection. See erlef/setup-beam#20 Also, run additional linting (except dialyzer) using latest Elixir/Erlang matrix. Co-authored-by: dorgan <dorgandash@gmail.com>
Remove extra redirection. See erlef/setup-beam#20
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-elixirtosetup-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 thatsetup-elixir@v1will continue to work as is.The text was updated successfully, but these errors were encountered: