Problem with debian/scripts/check-upstream

[Eloston]

On 89.0.4389.114-1.sid1, there is an issue when running debian/scripts/check-upstream (invoked by debian/scripts/setup local-src) exiting with this error:

symlink outside of pwd: ./tools/swarming_client/tests/trace_inputs/files2 files1

I've seen this in several recent versions already, and it seems to be a bug in check-upstream's code to detect whether a symlink will lead outside the pwd.

I am wondering: Does upstream Chromium run into this issue?

[Eloston]

@braewoods Do you run into this issue with OBS builds?

[ghost]

I don't believe so but then we don't use check-upstream in the normal build process to my knowledge. Here is the OBS log for that build. log.txt

[ghost]

I stand corrected. I forgot it's part of the source setup.

[ghost]

@Eloston How are you triggering it anyway?

[Eloston]

Okay, it's because my $(pwd) includes a symlinked directory. I'll need to change this line to cd into the real path

[ghost]

@Eloston Could you be more mindful about when you push to the repository while we're in the middle of preparing new releases? Your commit just reset my OBS build I was waiting for.

[Eloston]

Oh really? I didn't expect any push to re-trigger OBS builds. What is your procedure for releasing?

[ghost]

The scripts in each supported repository trigger an upload for every push or tag. Pushes go to the testing project's package(s) and tags to the production project's package(s). The idea was to allow development to trigger experimental OBS builds for whatever reason and link tagging releases to production OBS builds.

So I use normal pushes (or merges) to test that OBS can build the package prior to cutting an official production build. My containers aren't identical to OBS so I do this to ensure that I don't have any surprise failures.

[ghost]

Most of the time this is a non-issue but it is when I'm preparing to release for a major build.

[Eloston]

Hmm okay I see a few potential options here:

1. I just use PRs to make changes, so we can merge when we're not doing a release
2. We manually approve uploads to OBS instead of using pushes to the repo
3. We find a way to queue up or discard new uploads while a build is ongoing (instead of cancelling them). We can check if OBS has such an option, or if we can check in the Workflow before we perform the upload.

[ghost]

Option 1 is doable and is what I've been doing to date to reduce spurious builds being sent to OBS.

Option 2 isn't likely a good choice for all repositories due to needing access to the credentials to perform a manual upload. Unless you know some other trigger we could use.

Option 3 is partially implemented in that if the action is triggered while an upload is in progress the prior uploads will be canceled. But that won't help for ongoing builds.

[ghost]

Ok. Seems we could switch to using a manual trigger for testing uploads and continue using tags for production uploads.

[ghost]

I've implemented it. It will no longer trigger uploads on push.

[Eloston]

Huh, today I learned about Workflow Dispatch. Pretty neat, thanks!