#android #gradle #yaml #github-actions #bintray
#Android #gradle #yaml #github-действия #bintray
Вопрос:
У меня есть 3 секрета в настройках моего репозитория Github, в файле action workflow.yml
, где:
...
- name: Uploading to Bintray
env:
s1: ${{ secrets.SECRET_ONE }}
s2: ${{ secrets.SECRET_TWO }}
s3: ${{ secrets.SECRET_THREE }}
run: ./gradlew bintrayUpload
И мой deploy.gradle
:
configure<BintrayExtension> {
var ossPwd = ""
if (project.rootProject.file("local.properties").exists()) {
...
} else {
...
ossPwd = System.getenv("s3") ?: ""
}
pkg.apply {
...
version.apply {
if (ossPwd.isNotEmpty())
mavenCentralSync.apply {
...
password = ossPwd
}
}
}
}
System.getenv("s3")
выдает, null
пока SECRET_ONE и SECRET_TWO извлекаются правильно.
Есть причина, почему?
РЕДАКТИРОВАТЬ: я только что удалил (в 10-й раз) свой SECRET_THREE и создал еще 2 секрета. Все 4 были найдены и правильно использованы… ¯_(ツ)_/¯
Комментарии:
1. Настройка env находится на уровне шага, поэтому сомнение перезаписывается в рабочем процессе. Пожалуйста, убедитесь, что вы правильно определили имя secrets, или проверьте в своей команде run, чтобы убедиться, что оно не перезаписывается. Также переименуйте s3 env во что-то другое в качестве теста.
2. Я дважды проверил все секреты, включая удаление / создание снова. Последний шаг рабочего процесса опубликован выше, s3 он не перезаписан. Мой
deploy.gradle
также не переопределяет s3. Оба s1 и s2 в порядке, и логика одинакова, так странно… Я обновил свой вопрос, добавив немного больше кода.3. @GuilhE Можете ли вы установить
s3
какSystem.getenv("s3") ?: "xxx"
, просто чтобы перепроверить, определено ли оно там, и будет ли иметь значение »xxx
«?4. @GuilhE действительно странно. Я включил ваш комментарий в ответ для большей наглядности.
5. Рад, что вы разобрались. Такого рода проблема обычно связана с опечаткой в секретах.
Ответ №1:
Учитывая синтаксис рабочего процесса GitHub Actions для env
, все, что я вижу, это:
Когда определено более одной переменной среды с одинаковым именем, GitHub использует наиболее конкретную переменную среды.
- переменная среды, определенная на шаге, переопределяет переменные задания и рабочего процесса с тем же именем во время выполнения шага.
- Переменная, определенная для задания, переопределит переменную рабочего процесса с тем же именем во время выполнения задания.
Поэтому убедитесь, что ничто не переопределяет SECRET_THREE
или s3
само себя.
OP упоминает в комментариях:
Я только что удалил (в 10-й раз) свой
SECRET_THREE
и создал еще 2 секрета.
Все 4 были найдены и правильно использованы…¯_(ツ)_/¯
Я добавил это:
println("s3" System.getenv("s3").isNullOrEmpty "s4" System.getenv("s4").isNullOrEmpty
и это показало
s3falses4false
, и это сработало.
Комментарии:
1. SECRET_THREE — это секрет, а не env, поэтому это не применимо. Более вероятно, что OP неправильно устанавливает секрет из-за опечатки или переопределяет env s3 где-то внутри сценария запуска
2. @EdwardRomero docs.github.com/en/actions/configuring-and-managing-workflows /… : «Чтобы сделать секрет доступным для действия, вы должны установить секрет в качестве входных данных или переменной среды в файле рабочего процесса. » Это то, что сделал OP.
3. да, но он уже находится на уровне шага, как вы можете видеть из команды run. Так что нечего переопределять env. Если бы он добавил его на уровне задания или рабочего процесса, я бы согласился с вашим ответом. Но это не так.