8000 chore(main): release 3.1.0 by theoludwig · Pull Request #404 · editorconfig-checker/editorconfig-checker · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

chore(main): release 3.1.0 #404

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.

Sign up for GitHub

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

Jump to bottom
Closed
wants to merge 1 commit into from
Closed

chore(main): release 3.1.0 #404

wants to merge 1 commit into from

Conversation

theoludwig
Copy link
Member
@theoludwig theoludwig commented Jan 5, 2025 •
edited
Loading

🤖 I have created a release beep boop

3.1.0 (2025-01-06)

Features

  • add zip version when compressing all binaries (#321) (#362) (f1bb625)
  • consolidate adjacent error messages (#360) (cf4ae1c)
  • editorconfig-checker-disable-next-line (#363) (6116ec6)
  • provide Codeclimate compatible report fromat (#367) (282c315)
  • support .editorconfig-checker.json config (#375) (cb0039c)

Bug Fixes

This PR was generated with Release Please. See documentation.

@theoludwig theoludwig force-pushed the release-please--branches--main branch from c8656ee to c783c27 Compare January 5, 2025 23:22
@klaernie
Copy link
Member
klaernie commented Jan 5, 2025

Okay - finally figured out my error, but that is fixed now. Now it is in proper order.

It only remains to use the right token, but GITHUB_TOKEN is the wrong one - it would prevent from running the other workflows whenever a new PR is created/updated by release-please

@klaernie
Copy link
Member
klaernie commented Jan 5, 2025

Oh, btw: my suggestion would be to create a service user (e.g. editorconfig-checker-bot) to use in cases like these, where an action requires a token, but it would not be too fitting to use an actual human.

@theoludwig theoludwig force-pushed the release-please--branches--main branch from c783c27 to 8f589f9 Compare January 6, 2025 11:03
@theoludwig
Copy link
Member Author
theoludwig commented Jan 6, 2025 •
edited
Loading

Okay - finally figured out my error, but that is fixed now. Now it is in proper order.

Great, good job. 👍

It only remains to use the right token, but GITHUB_TOKEN is the wrong one - it would prevent from running the other workflows whenever a new PR is created/updated by release-please

Hmm, are you sure, GITHUB_TOKEN is the wrong one? I believe, it will work, and will use the github-actions user. At least, for my other projects, it's what I do, and it is able to create the GitHub release (I'm not using release-please, but semantic-release, but I guess the permissions needed for the token is the same for both).
Maybe, it's worth it, to try: Close this Pull Request, and use GITHUB_TOKEN instead?

Yeah, a service user would work, but maybe we can avoid the "hassle", and directly use the "bot user" already provided by GitHub?

@klaernie
Copy link
Member
klaernie commented Jan 6, 2025

Well, technically there is no "wrong one" - the limitation is, that release-please would create a pull request, but none of our CI would run, since GitHub does not trigger action execution when the action was done by an automatically provisioned token: https://github.com/googleapis/release-please-action?tab=readme-ov-file#github-credentials

Since we want to run both the CI and goreleaser when the release PR is merged, the token needs to be one that is not secrets.GITHUB_TOKEN.

@theoludwig
Copy link
Member Author

Well, technically there is no "wrong one" - the limitation is, that release-please would create a pull request, but none of our CI would run, since GitHub does not trigger action execution when the action was done by an automatically provisioned token: googleapis/release-please-action#github-credentials

Since we want to run both the CI and goreleaser when the release PR is merged, the token needs to be one that is not secrets.GITHUB_TOKEN.

Ah, I didn't know that, it wouldn't allow to trigger action with this token.
I'm making a GitHub account, @editorconfig-checker-bot, to use for this use case, it's better than using a personal account. I will close this PR, and recreate this with the "bot user".

@theoludwig theoludwig closed this Jan 6, 2025
@theoludwig theoludwig deleted the release-please--branches--main branch January 6, 2025 12:27
@klaernie
Copy link
Member
klaernie commented Jan 6, 2025 •
edited
Loading

I'm making a GitHub account, @editorconfig-checker-bot, to use for this use case, it's better than using a personal account. I will close this PR, and recreate this with the "bot user".

Awesome! Thanks for that! Do you have any idea or already-existing pattern for handling access to the bot account should you not be around? I'm just trying to make sure we have a future-proof setup not relying on a singular person.
My first instinct would be storing the password and two factor key in a sops encrypted file inside the repo, encrypting the master key to e.g. pgp keys for each of us.

@theoludwig
Copy link
Member Author

Awesome! Thanks for that! Do you have any idea or already-existing pattern for handling access to the bot account should you not be around? I'm just trying to make sure we have a future-proof setup not relying on a singular person. My first instinct would be storing the password and two factor key in a sops encrypted file inside the repo, encrypting the master key to e.g. pgp keys for each of us.

I don't know, I'm up to do something for this.
We will probably only use it for the release token.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
autorelease: pending
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@theoludwig @klaernie
0