Skip to content
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

feat: auto releasing ci #146

Merged
merged 5 commits into from Feb 7, 2021
Merged

feat: auto releasing ci #146

merged 5 commits into from Feb 7, 2021

Conversation

jef
Copy link
Contributor

@jef jef commented Feb 6, 2021

Description

I know there are a lot of changes and may warrant a bit of speculation, but I will try elaborate on what's going on here in a list below.

  • Introduces new action google-github-actions/release-please-action
    • I love this action because it manages releases for you.
    • Keeps a CHANGELOG based on Conventional Commits. This isn't necessary, but is cool feature.
    • Auto updates PR for next version.
    • You merge the PR when you're ready for release.
    • This means you push to master every commit and only when you merge the PR, it creates release assets and pushes to your latest-release branch (more on this later).
    • This includes auto updating the version in package.json.
  • Uploading release assets
    • Nothing really new here, but removes unnecessary zip action.
    • Changes zip name to be vuetorrent.zip rather than release.zip.
  • Pushes release automatically to latest-release
    • This part is sort of deceiving in the code because of the action name (JamesIves/github-pages-deploy-action). I have used this action in the past for GitHub pages, but this a great action for this use case.
    • What will happen is when we merge the release please PR, this action will build the project and publish to the branch, as it current is now (without a README). But we can easily update the project's README, to show how to use branch.
  • Changed when tests run
    • Nothing too crazy here, basically the same thing. But it makes sense to only run tests during pushes to master and pull requests to master in my opinion.

Kind of did this on a whim, but figured it would be really good to have something easier to manage!

Take a look at one of my repos and see how it publishes:

Feel free to ask any questions!

@WDaan
Copy link
Collaborator

WDaan commented Feb 7, 2021

Amazing! This is what I've been wanting/looking for for a long time and more!
Also thanks a lot for the detailed explanation & analysis, I really do appreciate it.
I would need to test a little before I implement it.

Questions:

  1. How does it know when to increment a major version number?

EDIT: I quickly tested it, looks awesome!

@jef
Copy link
Contributor Author

jef commented Feb 7, 2021

  1. How does it know when to increment a major version number?

Firstly, the versions get bumps based on the commit messages. In this case, that would mean PR titles since we use squash and merge method here (which is best is great!). That being said, there are two ways. One is using the main commit message or using the commit body:

  • PR Title: <type>(optional scope)!: <some message>
    • feat: changed something (minor bump)
    • changed something (patch bump, I think, not entirely sure)
    • feat!: changed something (major bump)
    • ci: changed something (no bump)
    • docs: changed something (no bump)
      PR Body (during commit):
- This adds/changes something
- This adds/changes something

BREAKING CHANGE: This changed

image

Only for major bumps, the commit (PR) body will do this. I usually just use the former.

You can see more on this here.

@jef
Copy link
Contributor Author

jef commented Feb 7, 2021

Also, if this gets merged in, I don't mind being on stand by to ensure everything goes smoothly. You just let me know what else you need from me and I can provide some examples or explanations!

@jef
Copy link
Contributor Author

jef commented Feb 7, 2021

I can update the README as well since some of the installation will change. Mostly just naming.

@WDaan
Copy link
Collaborator

WDaan commented Feb 7, 2021

Thanks! I also monitor it a little bit as well.

I think the only changes are the name of the .zip & the path of the latest-release branch. It seems like you directly upload what's inside of the public folder. Very smart utilisation of the github-pages action BTW!

Also, I think that de README in the latest-release branch will disappear on a new release?

@jef
Copy link
Contributor Author

jef commented Feb 7, 2021

Also, I think that de README in the latest-release branch will disappear on a new release?

Yep! Thanks right.

I figure that what we put in the README should be sufficient. If not, we can figure out a way to get it in there.

the path of the latest-release branch

This should be fine! I believe it will be publishing just the public/ folder.

@jef
Copy link
Contributor Author

jef commented Feb 7, 2021

Okay! I think it's good to go. Let me know if you need anything else.

@WDaan
Copy link
Collaborator

WDaan commented Feb 7, 2021

I also wanted to remove the old release script in this PR, because its kind off related

@jef
Copy link
Contributor Author

jef commented Feb 7, 2021

Great. Thanks for doing it. Commit looks great too 😉

@WDaan
Copy link
Collaborator

WDaan commented Feb 7, 2021

No, thank you! This is a big step in the right direction. It shows that the project is maturing a little bit.
Also decreases the risk of human errors etc

@jef
Copy link
Contributor Author

jef commented Feb 7, 2021

The workflows help a ton. I'll make a comment on the PR that gets created after this is merged.

@WDaan WDaan merged commit d217627 into VueTorrent:master Feb 7, 2021
@WDaan
Copy link
Collaborator

WDaan commented Feb 7, 2021

There seems to be a small mistake somewhere in both workflows

EDIT: fixed now

@jef jef deleted the feat/new-pipeline branch February 7, 2021 18:48
@jef
Copy link
Contributor Author

jef commented Feb 7, 2021

Oh whoops. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants