-
Notifications
You must be signed in to change notification settings - Fork 223
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
Usage without pull request #77
Comments
What is the overall workflow that you are trying to achieve? Should each merge to your base branch with at least one changeset result in an additional commit and immediate version bumps? 🤔 |
Yep, that is what I am going for. Release new packages as soon as the PR is merged This is the workflow I ended up creating
|
What about possible race conditions when merging stuff to your base branch in quick succession? It seems that this can easily amplify the problem 🤔 I'm wondering - is your action from the comment above pushing to the base branch? The version command in our actions switches to the |
I really wish GitHub actions had a way to serialize certain builds. There are a few different race conditions. If there was a race condition I use git as the lock in the above, one of the builds would fail because they would not be able to push I think |
Yeah, but not for base branch for next branch for doing pre-releases without having to merge them manually |
@Andarist now that some time has gone past, how would you feel about experimenting with a flow without the pull request? The main issue you validly raise is the extra commits and git conflicts that could come from versioning in an automatic flow. Semantic-Release solved this by being able to track versions in git tags only, which we already have in available in I'm not too familiar with the codebase, but suppose the biggest refactor/change is adding the logic to only track versions by git tags. I imagine the flow for a changeset user would be:
☝️ Note that no commits are necessary, users would leave their package versions in code at likely I'd be happy to help explore some of this 🤓 , I think of a lot of teams are torn between semantic-release and changesets. Having an automatic flow would be a huge benefit for teams looking to migrate. The |
From our side, we also usually have a |
I'd definitely like a way to autorelease patches from the github action. |
here is an auto publish action https://github.com/JamilOmar/autopublish-changesets-action |
Hey team,
I was just wondering if you had objections to a flag being passed which versioned direct on master (without going through the PR workflow).
The workflow I am thinking about has 2 jobs, the first simply runs changeset actions. If it versions any packages the second job will not run, the push would trigger master again which would release.
Otherwise I guess the manual way is to run
changeset version
, look for the warn that there are no packages to publish, then that is the flag to continue to next job?The text was updated successfully, but these errors were encountered: