Add an option to force rebuild of the remote build

[szymonrybczak]

Describe the feature

Motivation

Our goal should be to polish and take into account all cases, but for sure there'll be some scenarios that we cannot think of now, so in my opinion it could be handy to force a rebuild.

[mdjastrzebski]

Explain UX for that option.

Since remote build decision is made on the CI, that would mean like adding new param to workflow scripts, e.g. force-build. The potential issue with that solution is that someone leaves it turned on, which would waste a lot of CI resources on the client side, as builds would no longer cache based on finger print.

The current "solution" for triggering builds is deleting relevant artefact (one with matching fingerprint) which can be done on GH by navigating in the relevant workflow run and finding delete icons.

So perhaps we could have rnef delete-remote-build command or something similar to do this. Maybe even whole rnef remote-build list/remove/etc command. @szymonrybczak @thymikee let's discuss.

[thymikee]

Yeah I'm with Maciej on that. One can simply remove the artifact and the build will start again due to lack of cache.

[mdjastrzebski]

The only complication is finding the relevant build, as you have to go through each workflow run and manually look for matching fingerprint. We could improve this by surfacing the relevant workflow link from RNEF CLI, as we get that info from when fetching artifacts

[szymonrybczak]

Yeah, in the project that I needed to force rebuild my app I just followed the path with manually removing the artifact.

The idea with removing artifacts from command is nice, but the issue can be that someone removes the artifact and how we should inform on GitHub, should we send a comment that "Artifcact X was removed by @szymonrybczak, rebuilding.."?

Maybe for this flow to be more verbose maybe we should allow ping a bot to do it e.g. /rebase, so everyone will see what happend etc.

[mdjastrzebski]

BTW why did you force rebuilds?

[szymonrybczak]

In the app that I was integrating RNEF with I had a change in a local module under modules/name-of-the-module/android/some-native-file.kt and this directory wasn't tracked which IMO should be, it's linked in package.json, so the same copy of this directory lives under node_modules/name-of-the-module/... and the best part is that it was listed as the sources for the fingerprint but the hash was equal to null:

  {
    type: 'dir',
    filePath: 'node_modules/name-of-the-module',
    reasons: [ 'rncoreAutolinkingAndroid' ],
    hash: null
  },

On the other hand calculating hashes of directories for linked libraries in bigger projects might be expensive.

[mdjastrzebski]

Could null hash be result of symlinking?

[szymonrybczak]

It's null for every directory in node_modules that is tracked:

{
    type: 'dir',
    filePath: 'node_modules/react-native-haptic-feedback',
    reasons: [ 'rncoreAutolinkingAndroid' ],
    hash: null
  },
  {
    type: 'dir',
    filePath: 'node_modules/react-native-image-picker',
    reasons: [ 'rncoreAutolinkingAndroid' ],
    hash: null
  },
  {
    type: 'dir',
    filePath: 'node_modules/react-native-image-size',
    reasons: [ 'rncoreAutolinkingAndroid' ],
    hash: null
  },

[mdjastrzebski]

Are these directories empty or a symlink?

[szymonrybczak]

@mdjastrzebski there directories are normal dirs with all the files, I'm using npm as a package manager, so they're not linked on the package manager level neither.

[mdjastrzebski]

Either way looks like Expo fingerprint bug

[szymonrybczak]

Closing this one as we agreed on the experience that to force rebuild of an app should be done just by removing relevant artifact.