-
Notifications
You must be signed in to change notification settings - Fork 336
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'v1' release branch or tags to "release" an action #6
Comments
based on CR feedback from @jeffmcaffer - thanks! |
I am not sure about this approach, but I was thinking about pulling this out into an action of it's own. Thoughts? https://github.com/wesleytodd/meeting-maker/blob/master/test/_release.js What it does is create a single commit off of a version tag being pushed, then builds and commits specifically the |
@wesleytodd i'm becoming a bit disillusioned by that approach at present. Because actions don't yet support a "use-time compilation", having the compilation done in a script that only runs during a release flow makes it exceedingly more difficult for users to reference an unreleased action (ie, master) or to run off a fork. I do think this setup would be ideal in a future where actions has its own automatic compilation (for instance, running |
@jasonkarns - see actions/javascript-action, actions/setup-go, actions/setup-node etc. etc. They use ncc pack and there's no problem with master vs distribution branch. They're all the same with a dist folder. We won't be doing npm install at runtime - fragility, security (ref is what was reviewed) and we have GHES air gapped scenarios etc. What runs is an entry point and it has to be self container. ncc pack gives you that and you can ignore node_modules in every branch. Also see the workflow tests in this repo and those which reference Finally, we will be adding actions in GPR (a new type of package) at some point in the future (medium term backlog) as well. |
@bryanmacfarlane Ah, my mis-understanding was that @wesleytodd's proposal would have the dist folder only exist outside of master (ie, built only off tags). I didn't realize the intention was for that workflow to commit back to the main branches. mea culpa |
This is my intent. I will not be committing That said, I totally understand that this approach makes it more difficult to test builds. I think we can have the best of both worlds here with semver pre-release version. Push a tag like
Can you explain more about this? Would it follow semver without us having this sort of complicated setup in our actions? |
This includes To the original question:
I'm personally very strongly in favor of only using a vN branch. git-tags are not supposed to move, and I think it communicates a lot of bad practices to suggest a "blessed" workflow that involves force-pushing tags. (IMO) |
I am not sure I understand the reluctance to move tags, but if that is an issue for you we could do semver patterned branches just like the tags. I am not strongly opinionated on this part and both are trivial to implement. |
Change default value of slack channel
closing this since it is old and right now we are pushing tags forward. will reopen if we decide to change that approach. At this point I think we still should commit dist to master (which we do) and I agree about the point of "hey we can't test unreleased features unless master has dist". |
Should the walkthrough take the simple approach of a v1 branch or have a release branch where we push the tag along?
Also, we need to update the toolkit versioning doc and update the link here.
There's also the option of the simple approach in the walk through but then reference the versioning doc for more robust and complex options.
The text was updated successfully, but these errors were encountered: