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

[WIP] feat: add dependency management automation (#1676). #1677

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

aorinevo
Copy link
Contributor

@nknapp
Copy link
Collaborator

nknapp commented Apr 15, 2020

Thanks for this. It would be great to use semantic-release to do the actual release. It would simplify many things.

I think we should approach this in the following way:

  1. Add the semantic-release config to the 4.x-branch, but not the github-action. For the time being, we can run npx semantic-release locally but we can still revert to the old way of using yo release if it does not work as expected.
  2. Migrate travis and appveyor to github actions.
  3. Once we've confirmed that npx semantic-release covers the current release workflow and all targets, we can move it into the action.

Here are my pain points:

  • I am not sure that I know everything that yo release does in the background. I also don't know yet, what tasks/scripts npx semantic-release actually executes in order to build the project. But I am pretty sure that those are not the same at the moment. I want to test this manually before getting into automation.
  • My npm and gem accounts have MFA activated, which means that I have to enter an one-time-password when I publish packages. This is for a good reason: To prevent that something like the eslint-scope issue happens to Handlebars or other packages that I publish on npm. If we fully automate releases, I would like to maintain that level of security. I think we first have to explore the possibilities here.

I think it is acceptable to type npx semantic-release in order to get a new release. And it's a major improvement compared to what we have to do right now.

@jaylinski
Copy link
Member

It would be nice if we could do npm package provenance for verified builds:

https://github.blog/2023-04-19-introducing-npm-package-provenance/

@jaylinski jaylinski marked this pull request as draft September 6, 2023 21:31
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.

3 participants