Fail our CI when there are Git changes

[nilsreichardt]

To catch file changes like #506 or #510 on pull request level, we need to check in the our GitHub workflows if files have changed. If yes, we fail the workflow.

Closes #318

(Blocked by #510)

[docs-page]

To view this pull requests documentation preview, visit the following URL:

docs.page/sharezoneapp/sharezone-app~511

Documentation is deployed and generated using docs.page.

[github-actions]

Visit the preview URL for this PR (updated for commit c08d734):

https://sharezone-test--pr511-fail-on-git-diff-yrxeak22.web.app

_{(expires Wed, 22 Mar 2023 21:39:52 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

_{Sign: 4cb3ae61e1e018abfd9841fd3239f5b49ccc034b}

[Jonas-Sander]

But if we have the pubspec version foo_package: ^2.0.3 and foo_package: 2.0.4 is released then this would always fail until we update the constraint to foo_package: ^2.0.4 , wouldn't it? Since the new version will be used in the pubspec.lock and thus the file would be changed.

[nilsreichardt]

Hm, I'm not 100% sure. I need to check this.

An alternative idea would be to just post a comment as a warning. This would not fail our CI but prevents us from unintentionally forgetting to commit these files.

[nilsreichardt]

Idea:

• Write a GitHub Action that runs git diff
• If there are changed files, post a PR comment
  • Post the output of the git diff comment
  • If there is already a command, update the comment
  • If there are no diffs anymore, update the comment with something like: "✅ No diff changes anymore"

[nilsreichardt]

But if we have the pubspec version foo_package: ^2.0.3 and foo_package: 2.0.4 is released then this would always fail until we update the constraint to foo_package: ^2.0.4 , wouldn't it? Since the new version will be used in the pubspec.lock and thus the file would be changed.

Yes, this would be the case.

[Jonas-Sander]

If there is already a command, update the command

What do you mean with this?

[Jonas-Sander]

But if we have the pubspec version foo_package: ^2.0.3 and foo_package: 2.0.4 is released then this would always fail until we update the constraint to foo_package: ^2.0.4 , wouldn't it? Since the new version will be used in the pubspec.lock and thus the file would be changed.

Yes, this would be the case.

Hm, just by looking at dart pub get this actually wouldn't/shouldn't be the case (link):

If a lockfile already exists, dart pub get uses the versions of dependencies locked in it if possible. If a dependency isn’t locked, pub gets the latest version of that dependency that satisfies all the version constraints. This is the primary difference between dart pub get and dart pub upgrade, which always tries to get the latest versions of all dependencies.

Same for Flutter (link):

When running flutter pub get for the first time after adding a package, Flutter saves the concrete package version found in the pubspec.lock lockfile. This ensures that you get the same version again if you, or another developer on your team, run flutter pub get.

To upgrade to a new version of the package, for example to use new features in that package, run flutter pub upgrade to retrieve the highest available version of the package that is allowed by the version constraint specified in pubspec.yaml. Note that this is a different command from flutter upgrade or flutter update-packages, which both update Flutter itself.

Note a --enforce-lockfile flag is available for dart pub get but not flutter pub get.

[Jonas-Sander]

So from the behavior described in the docs this change should be fine, I think? I'm not 100% sure

[Jonas-Sander]

Idea:

* Write a GitHub Action that runs `git diff`

* If there are changed files, post a PR comment
  
  * Post the output of the `git diff` command
  * If there is already a command, update the command
  * If there are no diffs anymore, update the command with something like: "✅ No diff changes anymore"

Lets do this first and evaluate. We can change this to block later anyways.

[Jonas-Sander]

Hm, just by looking at dart pub get this actually wouldn't/shouldn't be the case (link):

If a lockfile already exists, dart pub get uses the versions of dependencies locked in it if possible. If a dependency isn’t locked, pub gets the latest version of that dependency that satisfies all the version constraints. This is the primary difference between dart pub get and dart pub upgrade, which always tries to get the latest versions of all dependencies.

Same for Flutter (link):

When running flutter pub get for the first time after adding a package, Flutter saves the concrete package version found in the pubspec.lock lockfile. This ensures that you get the same version again if you, or another developer on your team, run flutter pub get.
To upgrade to a new version of the package, for example to use new features in that package, run flutter pub upgrade to retrieve the highest available version of the package that is allowed by the version constraint specified in pubspec.yaml. Note that this is a different command from flutter upgrade or flutter update-packages, which both update Flutter itself.

Note a --enforce-lockfile flag is available for dart pub get but not flutter pub get.

Doesn't seem to be true, see #719
I'm confused.

[nilsreichardt]

Doesn't seem to be true, see #719
I'm confused.

What I tried:

Go into app/pubspec.lock change the version of feature_disctory from 0.14.0, safe the file and run fvm flutter pub get. It changes it back to 0.14.1.

If there is already a command, update the command

What do you mean with this?

Oh, I mean "comment" and not "command" 😂

Lets do this first and evaluate. We can change this to block later anyways.

We have the solution of this PR (just git diff --exit-code) since March for Family Missions and since then, we never had a false positive. So I think should be a good solution for now.

[Jonas-Sander]

What I tried:

Go into app/pubspec.lock change the version of feature_disctory from 0.14.0, safe the file and run fvm flutter pub get. It changes it back to 0.14.1.

Did you also update sha256 when updating the pubspec.lock?

What I tried now was:

• changing add_2_calendar in the pubspec.yaml from: ^2.1.1 to add_2_calendar: 2.1.1
• Run fvm flutter pub get
• This updated the pubspec.lock from using add_2_calendar 2.2.3 to 2.2.1
• Now I updated the pubspec.yaml back to ^2.1.1
• Run fvm flutter pub get
• The pubspec.lock version of add_2_calendar stayed at 2.1.1.

So in this case it did work...

[nilsreichardt]

Did you also update sha256 when updating the pubspec.lock?

Ah, no. This was my issue 👍