Skip to content

replace engine and framework mirror args with github username arg#109239

Merged
auto-submit[bot] merged 5 commits intoflutter:masterfrom
itsjustkevin:replace-mirror-args
Aug 10, 2022
Merged

replace engine and framework mirror args with github username arg#109239
auto-submit[bot] merged 5 commits intoflutter:masterfrom
itsjustkevin:replace-mirror-args

Conversation

@itsjustkevin
Copy link
Contributor

Remove the --framework-mirror and --engine-mirror args and replace them with the --github-username arg which interpolates the username into the framework and engine mirror urls.

@flutter-dashboard flutter-dashboard bot added the c: contributor-productivity Team-specific productivity, code health, technical debt. label Aug 9, 2022
@christopherfujino
Copy link
Contributor

this is fine as long as you're willing to accept the constraint that it will only ever work with a project name that matches the name of the canonical upstreams.

@itsjustkevin
Copy link
Contributor Author

@christopherfujino do you feel that this solution isn't generic enough?

I am looking at this from the perspective of the people currently using the release tooling, but I can absolutely see where this could be an issue down the line if we decide to make changes.

argumentResults,
platform.environment,
)!;
final String engineMirror = 'https://github.com/$githubUsername/engine.git';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if we share a common available GitHub account?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If that is the case, we could hardcode the mirrors and remove the argument completely. Do you see another approach I could take here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking at this comment again: What if the release team did share a common github account? We would probably still want some kind of mechanism to verify who is doing what under that shared account.

Will look further into this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly :-)

We could see if https://github.com/fluttergithubbot is ok to be used. We may need to lock it down so not all maintainers are able to contribute to the forks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened #109353 to track this.

@christopherfujino
Copy link
Contributor

@christopherfujino do you feel that this solution isn't generic enough?

I am looking at this from the perspective of the people currently using the release tooling, but I can absolutely see where this could be an issue down the line if we decide to make changes.

As a power user, I've definitely used the conductor on secondary/tertiary forks. It doesn't happen often, though.

@itsjustkevin
Copy link
Contributor Author

@christopherfujino do you feel that this solution isn't generic enough?
I am looking at this from the perspective of the people currently using the release tooling, but I can absolutely see where this could be an issue down the line if we decide to make changes.

As a power user, I've definitely used the conductor on secondary/tertiary forks. It doesn't happen often, though.

Thanks for pointing this out, I have not considered this use case. Open for suggestions.

Copy link
Contributor

@christopherfujino christopherfujino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Generally, most of the dart format changes here are against the repo's style guide: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#formatting

@itsjustkevin
Copy link
Contributor Author

Generally, most of the dart format changes here are against the repo's style guide: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#formatting

Do you have a VSCode settings.json file I could use to avoid this in the future? It would be nice if there was one available, there may be one already somewhere.

@christopherfujino
Copy link
Contributor

Generally, most of the dart format changes here are against the repo's style guide: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#formatting

Do you have a VSCode settings.json file I could use to avoid this in the future? It would be nice if there was one available, there may be one already somewhere.

It's trivial to globally disable autoformat on an editor level (https://linuxpip.org/vscode-format-on-save/#:~:text=Save%20not%20working-,Enable%2FDisable%20Format%20On%20Save,click%20on%20the%20right%20option.). I'm sure you could also do this on a language level for all Dart source files, but I'm not sure how to do it on a per-repo level (not sure if you submit patches to flutter/cocoon).

@itsjustkevin
Copy link
Contributor Author

Generally, most of the dart format changes here are against the repo's style guide: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#formatting

It's trivial to globally disable autoformat on an editor level (https://linuxpip.org/vscode-format-on-save/#:~:text=Save%20not%20working-,Enable%2FDisable%20Format%20On%20Save,click%20on%20the%20right%20option.). I'm sure you could also do this on a language level for all Dart source files, but I'm not sure how to do it on a per-repo level (not sure if you submit patches to flutter/cocoon).

Will update after reading the style guide fully.

Copy link
Contributor

@christopherfujino christopherfujino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor Author

@itsjustkevin itsjustkevin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

removed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

autosubmit Merge PR when tree becomes green via auto submit App c: contributor-productivity Team-specific productivity, code health, technical debt.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants