Add PULLREQUEST_DRONE_PULL_REQUEST drone env

[6543]

#3909 (comment)

cc @wez are you sure its PULLREQUEST_DRONE_PULL_REQUEST and not DRONE_PULL_REQUEST

[wez]

@6543 yeah, that env var is definitely the setting I use to get this particular thing to work

[6543]

@wez does the server run on x86 ?

[wez]

I run this particular configuration on amd64 and aarch64; so intel and arm, but 64-bit only

[wez]

For clarity, I have an amd64 agent and an aarch64 agent. They both build their respective platform packages and docker image, and they both have a step that tries to merge the other architectures together into a multiarch image with plugins/manifest, so I have merge-docker-image-arm and merge-docker-image step as platform-dependent steps in that particular matrix workflow, and they "race" to merge the manifest together. They are set to failure: ignore because one of them will always lose the race.

[6543]

Well in this case the server image woodpeckerci/woodpecker-server:pull_3939 (x84 only) in combination with the newest 2.7.0 agent images should do it

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 26.83%. Comparing base (7903d6f) to head (41dc7a2).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3939      +/-   ##
==========================================
+ Coverage   26.80%   26.83%   +0.02%     
==========================================
  Files         394      394              
  Lines       27496    27507      +11     
==========================================
+ Hits         7370     7381      +11     
  Misses      19425    19425              
  Partials      701      701              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[wez]

Thanks; I appreciate you doing this, but I'm not sure if I'll be able to try that out today ahead of this being merged as I had to roll back to 2.6 (and reinstall/reconfigure, because there isn't a backwards db migration!) and I had to unblock some other work for today.

[woodpecker-bot]

Tearing down https://woodpecker-ci-woodpecker-pr-3939.surge.sh

[wez]

FWIW, I got around to upgrading to 2.7.1 recently and I just noticed that this is failing for the non-pr case:

envconfig.Process: assigning PULLREQUEST_DRONE_PULL_REQUEST to Number: converting '' to type int. details: strconv.ParseInt: parsing "": invalid syntax

It seems like the compatibility layer doesn't guarantee that this env var is not set to an empty string somewhere.

woodpecker/pipeline/frontend/metadata/drone_compatibility.go

Lines 69 to 71 in 383bfbb

	if env["CI_COMMIT_PULL_REQUEST"] == "" {
	env["PULLREQUEST_DRONE_PULL_REQUEST"] = "0"
	}

this logic looks like it might potentially be problematic, because it checks a different variable for empty, but I think it is "fine" because the variable it checks was the source of this one. So it's probably ok?

Somehow the plugin thinks this env var is empty though.

I wonder if perhaps neither of these are set when building on the main branch, and that it is the plugin that is inferring an empty string?

Here's the definition of the struct in that plugin:
https://github.com/drone-plugins/drone-manifest/blob/af5721dace68ce1cacae7fccdf948efda66da35a/plugin/pipeline.go#L81-L84

	// PullRequest provides the pull request metadata.
	PullRequest struct {
		Number int `envconfig:"DRONE_PULL_REQUEST"`
	}

I'm not familiar enough with go to know how to reason about the behavior of this.

[6543]

@wez this patch is in the main branch targeting the release of v3.0.0 ... so it's not released jet

[6543]

or do you men to do:

 if env["CI_COMMIT_PULL_REQUEST"] == "" { 
 	env["PULLREQUEST_DRONE_PULL_REQUEST"] = "0"
+	env["DRONE_PULL_REQUEST"] = "0"
 }

?

[wez]

It not being present in 2.7.1 definitely explains it!

I think this might be clearer logic:

- if env["CI_COMMIT_PULL_REQUEST"] == "" { 
+ if env["PULLREQUEST_DRONE_PULL_REQUEST"] == "" { 
 	env["PULLREQUEST_DRONE_PULL_REQUEST"] = "0"
 }

I reverted back to the deprecated environment setting syntax, and my pipeline succeeds, so I think I'm good to punt until 3.0.0 is released. The only consequence is that it is flagged with 39 warnings, so it may be difficult to notice future issues. I'll survive :)

[6543]

ah @wez you struggle with the fact that if you set environment, the plugin will not be considered as plugin anymore ... (security stuff)

[wez]

I'm not sure that I understand what you mean there.

I have this in my config, on 2.7.1:

  merge-docker-image-arm:
    depends_on: [build-docker-image-arm]
    when:
      - evaluate: 'platform == "linux/aarch64" && UBUNTU_IMAGE == "ubuntu:22.04" && CI_PIPELINE_EVENT == "tag"'
    image: plugins/manifest
    failure: ignore
    environment: &docker_manifest_env
      # Legacy env var to prevent the plugin from throwing an error
      # when converting an empty string to a number
      PULLREQUEST_DRONE_PULL_REQUEST: 0
    settings: &docker_manifest_settings_tag
      <<: *docker_credentials
      target: "ghcr.io/kumocorp/kumomta-dev"
      template: "ghcr.io/kumocorp/kumomta:${CI_COMMIT_TAG}-ARCH"
      tags:
        - latest
        - ${CI_COMMIT_TAG}
      platforms:
        - linux/amd64
        - linux/arm64

the presence of the environment block yields a lot of warnings in the UI, but the step does run successfully.

I understand that the removal of the environment block is to address a potential security issue, but it doesn't appear to block me from running this config.