av9ash/GitBugs huggingface dataset:
Bug: HDFS rebalance commands
Status: Resolved | Priority: Minor | Resolution: Invalid
Created: 17/May/21 07:36

Team ,

Having 3 node cluster and one of the node 100% disk utilized . when i am trying to run rebalance commands by cli using (hdfs balancer -source 192.168.x.x) and even from ambari its not releasing space . Could you please  help me on this
Bug: Improve rendering of XML configuration files
Status: Open | Priority: Minor | Resolution: 
Created: 14/May/21 10:45

XML configuration files could be rendered more readable in web browsers by adding some CSS to the XSL. Cf. [Nutch 1.18 properties file|https://nutch.apache.org/apidocs/apidocs-1.18/resources/nutch-default.xml] and [configuration.xsl|https://github.com/apache/nutch/blob/master/conf/configuration.xsl].
Bug: Received "Permission denied" error while copying files through NFS Gateway
Status: Open | Priority: Minor | Resolution: 
Created: 04/May/21 07:59

In this case, while the file was copying through NFS gateway, the below permission error reports.
2021-03-29 05:19:13,389 INFO org.apache.hadoop.security.ShellBasedIdMapping: Update cache now
2021-03-29 05:19:13,399 WARN org.apache.hadoop.security.ShellBasedIdMapping: Can't find user name for uid 5999. Use default user name nobody
2021-03-29 05:19:13,412 INFO org.apache.hadoop.hdfs.nfs.nfs3.RpcProgramNfs3: Error writing to fileId 10131842296 at offset 3254190080 and length 32768
org.apache.hadoop.security.AccessControlException: Permission denied: user=nobody, access=EXECUTE, inode="/xxx":test:test:drwxrwx---

There is a map file exist, but never got changed.

Between Update Cache and Clear, some race conditions cause the unavailability of the user/group mapping from cache?
Bug: ITestWasbUriAndConfiguration.testCanonicalServiceName() failing now mockaccount exists
Status: Resolved | Priority: Minor | Resolution: Fixed
Created: 16/Apr/21 18:10
Affects Version/s: 3.2.1

The test ITestWasbUriAndConfiguration.testCanonicalServiceName() is failing in its intercept

[ERROR]   ITestWasbUriAndConfiguration.testCanonicalServiceName:656 Expected a java.lang.IllegalArgumentException to be thrown, but got the result: : "20.38.122.132:0"

Root cause is: the mock account in AzureBlobStorageTestAccount.MOCK_ACCOUNT_NAME is "mockAccount.blob.core.windows.net" and *someone has created that account*

This means it resolves
 nslookup mockAccount.blob.core.windows.net
Server:		172.18.64.15
Address:	172.18.64.15#53

Non-authoritative answer:
mockAccount.blob.core.windows.net	canonical name = blob.dsm08prdstr02a.store.core.windows.net.
Name:	blob.dsm08prdstr02a.store.core.windows.net
Address: 20.38.122.132
Bug: Replace Sets#newHashSet() and newTreeSet() with constructors directly
Status: In Progress | Priority: Trivial | Resolution: 
Created: 21/May/21 12:57
Affects Version/s: 3.3.5

 

As part of removing guava dependencies  HADOOP-17115, HADOOP-17721, HADOOP-17722 and HADOOP-17720 are fixed,

Currently the code call util function to create HashSet and TreeSet in the repo . These function calls dont have much importance as it is calling internally new HashSet<> / new TreeSet<> from java.utils 

This task is to clean up all the function calls to create sets which is redundant
Bug: Remove useless property hadoop.assemblies.version in pom file
Status: Resolved | Priority: Trivial | Resolution: Fixed
Created: 25/Apr/21 03:25
Affects Version/s: 3.3.1

The property hadoop.assemblies.version in hadoop-project/pom.xml is not used anywhere.

 

Remove it to avoid confusions. (As a matter of fact, this property was not updated in branch-3.3 and it remains to be 3.3.0-SNAPSHOT)
Bug: Fix for Javac Error of Unchecked Cast
Status: Open | Priority: Blocker | Resolution: 
Created: 03/Apr/23 11:14

This task is to fix javac unchecked cast error on yetus build.

Yetus checks on PR are failing at javac step with the error:
*"hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azure/security/TokenUtils.java:43:53:[unchecked] unchecked cast"*

This is blocking other PRs in the branches 3.3.3, 3.3.4, 3.3.2
This task will fix this error/warning and unblock other PRs.

Blocked PRs:
1. [Backport HADOOP-18546: ABFS: Disable purging list of in progress reads in abfs stream closed in 3.3.2 by anujmodi2021 · Pull Request #5529 · apache/hadoop (github.com)|https://github.com/apache/hadoop/pull/5529]
2. [Backport HADOOP-18546: ABFS: Disable purging list of in progress reads in abfs stream closed in 3.3.3 by anujmodi2021 · Pull Request #5530 · apache/hadoop (github.com)|https://github.com/apache/hadoop/pull/5530]
3. [Backport HADOOP-18546: ABFS: Disable purging list of in progress reads in abfs stream closed in 3.3.4 by anujmodi2021 · Pull Request #5531 · apache/hadoop (github.com)|https://github.com/apache/hadoop/pull/5531]
Bug: Remove mysql-connector-java
Status: Resolved | Priority: Blocker | Resolution: Fixed
Created: 09/Jun/23 01:04

While preparing for 3.3.6 RC, I realized the mysql-connector-java dependency added by HADOOP-18535 is GPL licensed.


Source: https://github.com/mysql/mysql-connector-j/blob/release/8.0/LICENSE 
See legal discussion at LEGAL-423.

I looked at the original jira and github PR and I don't think the license issue was noticed. 

Is it possible to get rid of the mysql connector dependency? As far as I can tell the dependency is very limited.

If not, I guess I'll have to revert the commits for now.
Bug: AWS v2 SDK: stabilise dependencies with rest of hadoop libraries
Status: Resolved | Priority: Blocker | Resolution: Not A Problem
Created: 17/May/23 10:31

 aws v2 sdk dependencies need to 

# be in sync with rest of hadoop
# not include anything coming in from hadoop common
# not export in hadoop-cloud-storage stuff from hadoop-common.

currently it is pulling in a version of jackson cbor whose consistency with hadoop's import is simply luck, joda time is also there

In an ideal world all this should be shaded: we cannot have the AWS sdk dictate what jackson version we ship with, given the history of downstream problems there.

{code}
[INFO] +- com.amazonaws:aws-java-sdk-core:jar:1.12.316:compile
[INFO] |  +- software.amazon.ion:ion-java:jar:1.0.2:compile
[INFO] |  +- com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:jar:2.12.7:compile
[INFO] |  \- joda-time:joda-time:jar:2.8.1:compile
[INFO] +- software.amazon.awssdk:bundle:jar:2.19.12:compile
[INFO] |  \- software.amazon.eventstream:eventstream:jar:1.0.1:compile
[INFO] +- software.amazon.awssdk.crt:aws-crt:jar:0.21.0:compile

{code}
Bug: 3.3.6 Release NOTICE and LICENSE file update
Status: Open | Priority: Blocker | Resolution: 
Created: 09/Jun/23 00:34
Affects Version/s: 3.3.6

As far as I can tell looking at hadoop-project/pom.xml the only difference between 3.3.5 and 3.3.6 from a dependency point of view is mysql connector (HADOOP-18535) derby (HADOOP-18535, HADOOP-18693).

Json-smart, snakeyaml and jetty, jettison are updated in LICENSE-binary already. grizzly was used in test scope only so its removal doesn't matter.
Bug: Hadoop build depends on archives.apache.org
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 27/Jun/23 18:38
Affects Version/s: 3.3.6

Several times throughout Hadoop's source, the ASF archive is referenced, including part of the build that downloads Yetus.

Building a release from source should not require access to the ASF archives, as that contributes to end users being subject to throttling and blocking by INFRA, for "abuse" of the archives, even though they are merely building a current ASF release from source. This is particularly problematic for downstream packagers who must build from Hadoop's source, or for CI/CD situations that depend on Hadoop's source, and particularly problematic for those end users behind a NAT gateway, because even if Hadoop's use of the archive is modest, it adds up for multiple users.

The build should be modified, so that it does not require access to fixed versions in the archives (or should work with the upstream of those dependent projects to publish their releases elsewhere, for routine consumptions). In the interim, the source could be updated to point to the current dependency versions available on downloads.apache.org.
Bug: [JDK-17] Failed unit tests , with Java 17 runtime and compiled Java 8
Status: Open | Priority: Critical | Resolution: 
Created: 24/Apr/23 07:21

Compiled Hadoop - Hadoop branch 3.3.3

mvn clean install - DskipTests=True

Java_Home ->  points to Java-8

maven version - 3.8.8 (Quite latest)

 

Ran various whole test suit on my private cloud environment -  

Changed Java_Home to   Java-17 

 

mvn surefire:test 

 

Out of 22k tests - 2.5 k tests failed .
Bug: Create qbt.sh symlink on Windows
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 06/May/23 12:29
Affects Version/s: 3.4.0

The hadoop-common project fails when mvnsite is built while running the shelldocs plugin on Windows 10 -

{code}
[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.1:exec (shelldocs) on project hadoop-common: Command execution failed. Process exited with an error: 1 (Exit value: 1) -> [Help 1]
{code}

This being the reason -

{code}
[INFO] --- exec-maven-plugin:1.3.1:exec (shelldocs) @ hadoop-common ---
tar: apache-yetus-0.14.0/lib/precommit/qbt.sh: Cannot create symlink to 'test-patch.sh': No such file or directory
tar: Exiting with failure status due to previous errors
ERROR: apache-yetus-0.14.0-bin.tar.gz is corrupt. Investigate and then remove /c/hadoop/patchprocess to try again.
{code}

The apache-yetus-0.14.0 tarball contains a symlink *qbt.sh*. Unzipping this tarball fails to create the qbt.sh symlink since the creation of symlink is limited to Admin or when the developer mode is enabled.

The solution here is to use the *ln* command to create the symlink and move it to the required target location
Bug: Fix incorrect output path in javadoc build phase
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 24/May/23 17:45
Affects Version/s: 3.4.0

The javadoc build phase fails with the following error -

{code}
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.0.1:javadoc-no-fork (default-cli) on project hadoop-common: An error has occurred in Javadoc report generation: Unable to write 'options' temporary file for command execution: H:\hadoop-common-project\hadoop-common\target\site\H:\hadoop-common-project\hadoop-common\target\api\options (The filename, directory name, or volume label syntax is incorrect) -> [Help 1]
{code}

As called out by the error message the path *H:\hadoop-common-project\hadoop-common\target\site\H:\hadoop-common-project\hadoop-common\target\api\options* is invalid.

The culprit being - https://github.com/apache/hadoop/blob/e9740cb17aef157a615dc36ae08cd224ce1672f0/hadoop-project-dist/pom.xml#L109

{code}
<reportOutputDirectory>${project.build.directory}/site</reportOutputDirectory>
<destDir>${project.build.directory}/api</destDir>
{code}

As per the [docs from maven-javadoc-plugin|https://maven.apache.org/plugins/maven-javadoc-plugin/examples/output-configuration.html], *destDir* attribute's value gets appended to that of *reportOutputDirectory*. This implies that *destDir* must be a relative path, although not called out in the documentation. Since this isn't the case here,
# In Linux, this yields an unintended path (albeit a valid one) and doesn't fail.
# In Windows, it yields an incorrect path and thus fails since there's a colon ( : ) for the drive letter in the middle of the incorrectly concatenated path -
H:\hadoop-common-project\hadoop-common\target\site\H {color:red}*:*{color} \hadoop-common-project\hadoop-common\target\api\options

Thus, fixing this would fix the build failure on Windows and put the docs in the appropriate directory in Linux.
Bug: Open file fails with NumberFormatException for S3AFileSystem
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 28/Apr/23 13:13
Affects Version/s: 3.3.5

Saw the trace for Hive-Iceberg, was using the old client, doesn't happen once I upgraded.
{noformat}
Caused by: java.lang.NumberFormatException: For input string: "5783.0"
	at java.base/java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
	at java.base/java.lang.Long.parseLong(Long.java:692)
	at java.base/java.lang.Long.parseLong(Long.java:817)
	at org.apache.hadoop.conf.Configuration.getLong(Configuration.java:1601)
	at org.apache.hadoop.fs.s3a.impl.OpenFileSupport.prepareToOpenFile(OpenFileSupport.java:262)
	at org.apache.hadoop.fs.s3a.S3AFileSystem.openFileWithOptions(S3AFileSystem.java:5219)
	at org.apache.hadoop.fs.FileSystem$FSDataInputStreamBuilder.build(FileSystem.java:4753)
	at org.apache.iceberg.hadoop.HadoopInputFile.newStream(HadoopInputFile.java:196)
	at org.apache.iceberg.avro.AvroIterable.newFileReader(AvroIterable.java:101)
	at org.apache.iceberg.avro.AvroIterable.getMetadata(AvroIterable.java:66){noformat}
Bug: Fix mvnsite on Windows 10
Status: Resolved | Priority: Critical | Resolution: Fixed
Created: 04/May/23 14:17
Affects Version/s: 3.4.0

The mvnsite step fails to build on Windows 10 due to the following error -

[ERROR] Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.3.1:exec (shelldocs) on project hadoop-common: Command execution failed. Cannot run program "C:\hadoop\hadoop-common-project\hadoop-common\..\..\dev-support\bin\shelldocs" (in directory "C:\hadoop\hadoop-common-project\hadoop-common\src\site\markdown"): CreateProcess error=193, %1 is not a valid Win32 application -> [Help 1]

shelldocs is a bash script which Windows can't execute natively. Thus, we need to run this through bash on Windows 10.
Bug: Change fs.s3a.directory.marker.retention to "keep"
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 24/May/23 17:53
Affects Version/s: 3.3.5

Change the default value of "fs.s3a.directory.marker.retention" to keep; update docs to match.

maybe include with HADOOP-17802 so we don't blow up with fewer markers being created.
Bug: zk 3.3.6 adds in slf-log4j dependencies to hadoop-common
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 28/Jun/23 14:19
Affects Version/s: 3.3.9

seeing this building against the hadoop aws v2 + branch-33 feature branch, so if it's been fixed in the main please close.

My downstream code is printing errors in test run because of conflicting slf4j appenders. the root cause appears to be that zk 3.3.6 is pulling in log4j rather than relog4j; both end up on the classpath downstream for much pain.

proposed: exclude it
Bug: Client.Connection#updateAddress needs to ensure that address is resolved before updating
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 10/Apr/23 13:47
Affects Version/s: 3.3.5

When Client.Connection#setupConnection encounters an IOException, it will try to update the server address. ([HADOOP-18365|https://issues.apache.org/jira/browse/HADOOP-18365])

When the address is re-parsed, it may be an unresolved address (UnknownHostException), which causes Client.Connection#setupConnection to fail to reconnect.
{code:java}
while (true) {
  try {
    if (server.isUnresolved()) { {code}
Especially when DN is connected to NN, BPServiceActor#bpNamenode is only initialized once, which causes DN to never connect to NN before restarting.
Bug: S3A: Test failures with CSE enabled
Status: Resolved | Priority: Major | Resolution: Cannot Reproduce
Created: 20/Jun/23 12:44

The following tests fail when run hadoop-aws suite is run with CSE enabled:

 

{{ITestS3APrefetchingInputStream.testRandomReadLargeFile}}
{{ITestS3APrefetchingInputStream.testReadLargeFileFully}}
{{ITestS3APrefetchingInputStream.testReadLargeFileFullyLazySeek}}
{{ITestS3ARequesterPays.testRequesterPaysOptionSuccess}}
{{ITestAssumeRole.testReadOnlyOperations }}
{{ITestPartialRenamesDeletes.testRenameParentPathNotWriteable}}
{{ITestPartialRenamesDeletes.testRenameParentPathNotWriteable}}
{{ITestS3GuardTool.testLandsatBucketRequireUnencrypted}}

 

Most of these are because they're using landsat data which is not encrypted, so trying to read with a CSE will fail. These tests should be skipped if using CSE.
Bug: ITestS3ABlockOutputArray failure with IO File name too long
Status: Open | Priority: Major | Resolution: 
Created: 18/May/23 08:50

On an EC2 instance, the following tests are failing:

 

{{{}ITestS3ABlockOutputArray.testDiskBlockCreate{}}}{{{}ITestS3ABlockOutputByteBuffer>ITestS3ABlockOutputArray.testDiskBlockCreate{}}}{{{}ITestS3ABlockOutputDisk>ITestS3ABlockOutputArray.testDiskBlockCreate{}}}

 

with the error IO File name too long. 

 

The tests create a file with a 1024 char file name and rely on File.createTempFile() to truncate the file name to < OS limit. 

 

Stack trace:

{{Java.io.IOException: File name too long}}
{{    at java.io.UnixFileSystem.createFileExclusively(Native Method)}}
{{    at java.io.File.createTempFile(File.java:2063)}}
{{    at org.apache.hadoop.fs.s3a.S3AFileSystem.createTmpFileForWrite(S3AFileSystem.java:1377)}}
{{    at org.apache.hadoop.fs.s3a.S3ADataBlocks$DiskBlockFactory.create(S3ADataBlocks.java:829)}}
{{    at org.apache.hadoop.fs.s3a.ITestS3ABlockOutputArray.testDiskBlockCreate(ITestS3ABlockOutputArray.java:114)}}
{{    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)}}
{{    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)}}
{{    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)}}
Bug: [ABFS][Backoff-Optimization] Have a Static retry policy for connection timeout failures
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 02/Jun/23 11:35
Affects Version/s: 3.3.4

Today when a request fails with connection timeout, it falls back into the loop for exponential retry. Unlike Azure Storage, there are no guarantees of success on exponentially retried request or recommendations for ideal retry policies for Azure network or any other general failures. Faster failure and retry might be more beneficial for such generic connection timeout failures. 

This PR introduces a new Static Retry Policy which will currently be used only for Connection Timeout failures. It means all the requests failing with Connection Timeout errors will be retried after a constant retry(sleep) interval independent of how many times that request has failed. Max Retry Count check will still be in place.

Following Configurations will be introduced in the change:
 # "fs.azure.static.retry.for.connection.timeout.enabled" - default: true, true: static retry will be used for CT, false: Exponential retry will be used.
 # "fs.azure.static.retry.interval" - default: 1000ms.

This also introduces a new field in x-ms-client-request-id only for the requests that are being retried after connection timeout failure. New filed will tell what retry policy was used to get the sleep interval before making this request.
Header "x-ms-client-request-id " right now has only the retryCount and retryReason this particular API call is. For ex:  :eb06d8f6-5693-461b-b63c-5858fa7655e6:29cb0d19-2b68-4409-bc35-cb7160b90dd8:::CF:1_CT.

Moving ahead for retryReason "CT" it will have retry policy abbreviation as well.
For ex:  :eb06d8f6-5693-461b-b63c-5858fa7655e6:29cb0d19-2b68-4409-bc35-cb7160b90dd8:::CF:1_CT_E.
Bug: ABFS backReference passed down to streams to avoid GC closing the FS.
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 23/Jun/23 04:03

Applications using AzureBlobFileSystem to create the AbfsOutputStream can use the AbfsOutputStream for the purpose of writing, however, the OutputStream doesn't hold any reference to the fs instance that created it, which can make the FS instance eligible for GC, when this occurs, AzureblobFileSystem's `finalize()` method gets called which in turn closes the FS, and in turn call the close for AzureBlobFileSystemStore, which uses the same Threadpool that is used by the AbfsOutputStream. This leads to the closing of the thread pool while the writing is happening in the background and leads to hanging while writing.

 

*Solution:*
Pass a backreference of AzureBlobFileSystem into AzureBlobFileSystemStore and AbfsOutputStream as well.

 

Same should be done for AbfsInputStream as well.
Bug: Bump jettison from 1.5.3 to 1.5.4 in /hadoop-project
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 01/Apr/23 19:16
Affects Version/s: 3.3.9

PR from github depandabot 
https://github.com/apache/hadoop/pull/5502

Mentions CVE: https://nvd.nist.gov/vuln/detail/CVE-2023-1436

Creating ticket for tracking.
Bug: Add a CallerContext getter on the Schedulable interface
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 06/Apr/23 17:41
Affects Version/s: 3.3.6

We would like to add a default *{color:#00875a}CallerContext{color}* getter on the *{color:#00875a}Schedulable{color}* interface
{code:java}
default public CallerContext getCallerContext() {
  return null;  
} {code}
and then override it on the *{color:#00875a}i{color}{color:#00875a}{*}pc/{*}Server.Call{color}* class
{code:java}
@Override
public CallerContext getCallerContext() {  
  return this.callerContext;
} {code}
to expose the already existing *{color:#00875a}callerContext{color}* field.

 

This change will help us access the *{color:#00875a}CallerContext{color}* on an Apache Ozone *{color:#00875a}IdentityProvider{color}* implementation.

On Ozone side the *{color:#00875a}FairCallQueue{color}* doesn't work with the Ozone S3G, because all users are masked under a special S3G user and there is no impersonation. Therefore, the FCQ reads only 1 user and becomes ineffective. We can use the *{color:#00875a}CallerContext{color}* field to store the current user and access it on the Ozone {*}{color:#00875a}IdentityProvider{color}{*}.

 

This is a presentation with the proposed approach.

[https://docs.google.com/presentation/d/1iChpCz_qf-LXiPyvotpOGiZ31yEUyxAdU4RhWMKo0c0/edit#slide=id.p]
Bug: Add curator based ZooKeeper communication support over SSL/TLS into the common library
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 19/Apr/23 15:00
Affects Version/s: 3.4.0

With HADOOP-16579 the ZooKeeper client is capable of securing communication with SSL. 

To follow the convention introduced in HADOOP-14741, proposing to add to the core-default.xml the following configurations, as the groundwork for the components to enable encrypted communication between the individual components and ZooKeeper:
 * hadoop.zk.ssl.keystore.location
 * hadoop.zk.ssl.keystore.password
 * hadoop.zk.ssl.truststore.location
 * hadoop.zk.ssl.truststore.password

These parameters along with the component-specific ssl.client.enable option (e.g. yarn.zookeeper.ssl.client.enable) should be passed to the ZKCuratorManager to build the CuratorFramework. The ZKCuratorManager needs a new overloaded start() method to build the encrypted communication.
 * The secured ZK Client uses Netty, hence the dependency is included in the pom.xml. Added netty-handler and netty-transport-native-epoll dependency to the pom.xml based on ZOOKEEPER-3494 - "No need to depend on netty-all (SSL)".
 * The change was exclusively tested with the unit test, which is a kind of integration test, as a ZK Server was brought up and the communication tested between the client and the server.
 * This code change is in the common code base and there is no component calling it yet. Once YARN-11468 - "Zookeeper SSL/TLS support" is implemented, we can test it in a real cluster environment.
Bug: Avoid cross-platform build for irrelevant Dockerfile changes
Status: Resolved | Priority: Major | Resolution: Fixed
Created: 30/Apr/23 19:28
Affects Version/s: 3.4.0

Currently, when one of the Dockerfiles (located at https://github.com/apache/hadoop/tree/trunk/dev-support/docker) changes, all the platform builds are run.
For example, a change to Dockerfile_debian_10 would trigger a run for Centos 7, which isn't relevant.
This leads to unnecessary delays in PR validation. We should thus limit the changes specific to the platform for the case where the corresponding Dockerfile changes.