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

Make the update helper command easier to run #108

Open
omarlopesino opened this issue Feb 16, 2023 · 5 comments
Open

Make the update helper command easier to run #108

omarlopesino opened this issue Feb 16, 2023 · 5 comments

Comments

@omarlopesino
Copy link
Member

Problem description

Currently, the update helper command needs a list of parameters that are always repeated: the author and the environment list (drush aliases of the local sites). The main problem is that the environment list may become pretty large and missing one environment leads to the configuration of that site not being correctly consolidated. Also, the author's parameter syntax may become tricky and can lead to human errors.

Proposed solution

Create two make commands:

  • One that updates all packages.
  • Other than updates only securities.

The author and the environment will be configurable in the Makefile. The environment list must be the list of drush aliases, each alias is a specific site of the project.

The author is the git commit author of the updates, it will be always the same. It must be decided by the team thinking that the author should be a git user that will never be removed from the project. So it should be a development account that is not related to any developer that may leave the project.

Pending tasks

How to set the author in composer create-project installations. if it is not set, the make update command won't work the first time.

Proposed solutions:

a) Ask for the git author in the composer create-project execution.
b) Set the git author in the composer create-project execution with the current git author information of the local user.

omarlopesino added a commit that referenced this issue Feb 16, 2023
@omarlopesino
Copy link
Member Author

I would like opinion about what is commented in the Pending tasks section.

In my opinion I think a) is okay but I would like to know if it is okay for everyone.

About the b) solution, I think it will lead to adding the developer author to all the updates done and that leads to:

  • If the developer leaves the project, the author becomes obsolete.
  • If there is a regression it may be thought that the developer that appears in the commit author is the responsible, when it may be possible that developer didn't make the updates.

cc @jorgetutor @rsanzante @juanjol

@jorgetutor
Copy link
Member

IMO the update command should use a default git user if the param is not set or empty, something generic like "script@drupal-update" (thinking in the new name of the repository). I think this is key, as the script can be run without the boilerplate

The make file will have this declared but empty, and the user can change it manually or as part of the composer install.

@rsanzante
Copy link
Member

There are two situations where this command is run:

  1. A dev runs it on their local machine
  2. An automated agent runs it

On case 1) I think commits should have the dev's Git info because that dev is directly responsible of the commits.
On case 2) I agree commits should be done by a Git user related to the agent that performs the update action.

We can do this:

  • By default, the command to pull the git info from local user. This way, command will automatically commit using dev's Git info when they all working in their local machine without any extra param.
  • Automatic agent needs to pass a flag to the command to instruct it to use a defined git info (name and email) from a project configuration. Shouldn't be hard to add that parameter when the script is run by an agent.

I'm not sure were to save that info. The Makefile seems like a bad place because it a file with commands. It should read the conf from another place. The .env file is an option, but that's relates to and environment, not the whole project.

About getting the Git info to store, I guess it is ok to ask it on the create project run.

@rsanzante
Copy link
Member

I agree on the default fallback when there's no git info available.

@omarlopesino
Copy link
Member Author

AFter a talk we have decided to not add the author. The update helper script will add a default author if it is not set. Thanks for the proposals.

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

No branches or pull requests

3 participants