AWS Cloud Map

Cloud Map allows you to register any application resources such as databases, queues, microservices, and other cloud resources with custom names. Cloud Map then constantly checks the health of resources to make sure the location is up-to-date. The application can then query the registry for the location of the resources needed based on the application version and deployment environment.
https://aws.amazon.com/ru/about-aws/whats-new/2018/11/introducing-aws-cloud-map/

https://aws.amazon.com/ru/blogs/aws/aws-cloud-map-easily-create-and-maintain-custom-maps-of-your-applications/

Video:
https://www.youtube.com/watch?v=fMGd9IUaotE

Jenkins: пропускаем шаг начальной настройки

При автоматической выкатке часто надо пропустить шаг настройки (мастер), есть несколько способов
1) java  -Djenkins.install.runSetupWizard=false -jar jenkins.war
Вариант через переменную (для докера)
ENV JAVA_OPTS "-Djenkins.install.runSetupWizard=false ${JAVA_OPTS:-}"

2) поставить плагин jcasc и при влитом конфиге он должен визард пропускать. Но не всегда, например https://github.com/jenkinsci/configuration-as-code-plugin/issues/393, поэтому 1 метод предпочтительнее.

3) Не проверялось, но иногда встречается в гугле
echo ${JENKINS_VERSION} > ${JENKINS_HOME}/jenkins.install.UpgradeWizard.state

Accessing and dumping Jenkins credentials

https://codurance.com/2019/05/30/accessing-and-dumping-jenkins-credentials/

Jenkins pipeline jobs

Помимо Freestyle задач, если pipeline, это код на груви. Главные преимущества - переносимость, возможность держать конфиги в системе контроля версий, сами pipelines можно прямо из гита вызывать, можно код положить в Jenkinsfile и передавать вместе с проектом.
Минусы - сложность освоения, зачастую совершенно невнятные ошибки, что раньше в вебе накликивалось за пол часа, теперь надо долго и вдумчиво писать.
Чуть добавляет сложности то, их несколько видов, и они не очень совместимы.
По синтаксису: scripted, declarative
Pipeline, multibranch pipeline

Intro
https://jenkins.io/doc/book/pipeline/getting-started/
https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md

Next
https://jenkins.io/doc/book/pipeline/syntax/

2 models
https://jenkins.io/doc/pipeline/steps/pipeline-model-definition/

For plugins
https://jenkins.io/doc/pipeline/steps/

Очень достойные документы, где описано очень много полезного. post, when... Хотя бы по диагонали но прочитать.
https://www.blazemeter.com/blog/how-to-use-the-jenkins-scripted-pipeline/
https://www.blazemeter.com/blog/how-to-use-the-jenkins-declarative-pipeline/

Advanced:
https://www.cloudbees.com/blog/top-10-best-practices-jenkins-pipeline-plugin

PS
Раньше формат вызова плагинов был примерно таким
step([$class: 'ArtifactArchiver', artifacts: 'something'])
В новом синтаксисе (года с 2016) это гораздо читаемее и сокращается до
archiveArtifacts 'something'
Но. Не всегда. Например, в 2020 у плагина Mailer существует только такой формат вызова
step([$class: 'Mailer']): E-mail Notification
https://jenkins.io/doc/pipeline/steps/mailer/

Чуть больше про это
https://stackoverflow.com/questions/48797509/class-syntax-in-jenkins-scripted-dsl

PS2
When a recorder is run from a pipeline, it might set the build’s status (for example to unstable), but otherwise is likely to work intuitively. Running a notifier is trickier since normally a pipeline in progress has no status yet, unlike a freestyle project whose status is determined before the notifier is called. To help interoperate better with these, you can use the catchError step, or manually set a build status using currentBuild.result. See the help for the catchError step for examples.

https://github.com/jenkinsci/workflow-basic-steps-plugin/blob/master/src/main/resources/org/jenkinsci/plugins/workflow/steps/CatchErrorStep/help.html
catchError : This step is most useful when used in Declarative Pipeline or with the options to set the stage result or ignore build interruptions. Otherwise, consider using plain try-catch-finallyblocks.

Mac: Нормальный вывод du

Не знаю какие дендропришельцы делали вывод для du, штатно это что-то совершенно нечитаемое и бесполезное, и даже -h не улучшает ситуацию.
Правильная команда:
df -lHPh
И в конфиг ~/.bash_profile
alias du='df -lHPh'

Jenkins: передача параметров между задачами

Иногда (часто) есть несколько задач, между которыми надо передавать аргументы.
В случае, если первая задача хочет запустить вторую, тут очень просто. Ставим плагин Parameterized Trigger plugin, во второй задаче перечисляем что мы хотим получать, а в первой добавляем шаг сборки "Trigger/Call builds on other projects" и там есть поле для переменных, которые мы передаём, формат обычный, NEW_VAR=some_var
как-то так
А вот от второй задачи к первой - весьма сложно. Пожалуй, самым простым вариантом - во второй задаче выводим нужные переменные в файл, а в первой импортируем переменные из файла, через шаг сборки Inject environment variables. То есть через trigger build запускаем вторую задачу, там внутри пишем нужные переменные в общедоступный файл (поэтому будет работать только внутри 1 сервера, и папки лучше всего брать $HOME или /tmp), а следущим шагом через inject читаем переменные, формат переменных обычный, на строку VAR="value", сам путь в Properties File Path
примерно так