:) lpsm-dev

Prompts

Utilize o princípio 80/20 para aprender mais depressa

Quero aprender sobre [inserir tópico]. Identificar e partilhar os 20% de aprendizagens mais importantes deste tópico que me ajudarão a compreender 80% do mesmo.

Melhore a sua escrita obtendo feedback

[Colar a sua redação]

The components of GitHub Actions

There are several components that work together to run tasks or jobs within a GitHub Actions workflow. In short, an event triggers the workflow, which contains a job. This job then uses steps to dictate which actions will run within the workflow. To better see how these components work together, let's take a quick look at each one.

Workflows

A workflow is an automated process that you add to your repository. A workflow needs to have at least one job, and different events can trigger it. You can use it to build, test, package, release, or deploy your repository's project on GitHub.

It's essential to follow best practices when creating actions:

Create chainable actions. Don't create large monolithic actions. Instead, create smaller functional actions that can be chained together.
Version your actions like other code. Others might take dependencies on various versions of your actions. Allow them to specify versions.
Provide the latest label. If others are happy to use the latest version of your action, make sure you provide the latest label that they can specify to get it.
Add appropriate documentation. As with other codes, documentation helps others use your actions and can help avoid surprises about how they function.
Add details action.yml metadata. At the root of your action, you'll have an action.yml file. Ensure it has been populated with author, icon, expected inputs, and outputs.
Consider contributing to the marketplace. It's easier for us to work with actions when we all contribute to the marketplace. Help to avoid people needing to relearn the same issues endlessly.

kubectl exec -it <pod-name> -- sh

psql -h localhost -p 5432 -U sonarUser sonarDB

select * from users;

	🌞 Morning 371 commits ████▉░░░░░░░░░░░░░░░░ 23.4%
	🌆 Daytime 381 commits █████░░░░░░░░░░░░░░░░ 24.0%
	🌃 Evening 521 commits ██████▉░░░░░░░░░░░░░░ 32.8%
	🌙 Night 314 commits ████▏░░░░░░░░░░░░░░░░ 19.8%

	resource "tfe_workspace" "this" {
	for_each = local.tfc_workspaces

	name = "${local.tfc_project}-${each.key}"
	organization = data.tfe_organization.this.name
	project_id = tfe_project.this.id
	auto_apply = false
	force_delete = true
	global_remote_state = true
	trigger_patterns = try(each.value.custom_trigger_patterns, ["./${each.key}/*"])

	$headers = @{ Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN" }
	$orgName = $env:ORG_NAME
	$projectName = $env:SYSTEM_TEAMPROJECT
	$releaseRefId = $env:RELEASE_REF_ID
	$releaseRefStageName = $env:RELEASE_REF_STAGE_NAME

	Write-Host "======================================================="

	$releasRefURL = "https://vsrm.dev.azure.com/$orgName/$projectName/_apis/release/releases?definitionId=$releaseRefId&api-version=5.1"
	Write-Host "=> Release Ref URL: [$releasRefURL]"

	#!/bin/bash

	# Define variables
	SONARQUBE_TOKEN=""
	SONARQUBE_URL=""
	QUALITY_GATE_NAME=""
	PROJECT_KEY=""

	# Get quality gate ID
	QUALITY_GATE_ID=$(curl -s -u $SONARQUBE_TOKEN: -X GET "$SONARQUBE_URL/api/qualitygates/list" \| jq -r '.qualitygates[] \| select(.name=="'"$QUALITY_GATE_NAME"'") \| .id')

	user = User.new(username: 'user', email: '[email protected]', name: 'user', password: 'user', password_confirmation: 'user')
	# Use it only if you wish user to be automatically confirmed. If skipped, user receives confirmation e-mail
	user.skip_confirmation!
	user.admin = true
	user.save!