小编Nie*_*els的帖子

我有一个带有Jenkinsfile的GitHub存储库设置。GitHub Organization Folder插件将从提供的Jenkinsfile执行管道。

管道的最后一步是部署步骤。部署步骤使用CloudBees Amazon Web Services凭据插件检查分支是否具有AWS凭据。如果检测到凭据，它将部署，否则将不会部署。

每当他们想要更改某些内容时，所有成员都具有对GitHub存储库的只读访问权限，他们必须创建拉取请求。（只有管理员可以合并）如果有新的拉取请求，Jenkins服务器将运行管道直到部署步骤，检查拉取请求是否可以集成到master分支中。管道的最后一步是部署步骤，不应对请求请求执行此步骤。

stage('Deploy') {

    // Deploy with the right credentials
    try {
        withCredentials([[
            $class: 'AmazonWebServicesCredentialsBinding', 
            accessKeyVariable: 'AWS_ACCESS_KEY_ID', 
            credentialsId: env.BRANCH_NAME + '_AWS_Credentials', 
            secretKeyVariable: 'AWS_SECRET_ACCESS_KEY'
        ]]) {
            echo("Deploying to " + env.BRANCH_NAME + "...")
            ...
        }
    } catch(all) {
        echo("Not deploying for branch: " + env.BRANCH_NAME)
    }
}

问题在于团队成员可以使用更改后的Jenkinsfile创建请求请求。

假设有一个团队成员被黑了。他们现在可以通过创建具有更改的Jenkinsfile的拉取请求来感染生产环境，该请求执行以下操作：

credentialsId: 'master_AWS_Credentials', 

如何防止Jenkins为更改的Jenkinsfile运行管道？还是如何使用master分支中的Jenkinsfile发出拉取请求？

如何检测用户是否使用Hololens访问您的网站？

hololens的用户代理似乎与Edge使用的用户代理相同.