For this part, you will have to trigger the workflow under specific conditions. Each item on the list correspond to a particular scenario where the workflow should (or should not) run.
- Create and publish 3 branches, "dev", "staging", "feat/feature-1"
- When you have a push on the branch "dev" only
- When you have a push on any branch except "staging"
- When you have a push on any branch where the name starts with "feat"
- When only the files with a ts extension have been modified
- When a specific folder have been modified
- When someone creates a PR
- When someone closed a PR
- Every minutes
- Every 1h 30m
- Every Tuesday at 3am
- Create two jobs inside a new workflow
- When you have a push, execute both job
- When you have a PR, execute only the first job.
- Create a dev branch, and inside it create a dummy change.txt file. Put your name in it. Publish this branch
- Create a pull request from the dev branch to main. You should see the first job executing directly inside the PR (from the github UI)
- When you click on run workflow button in the UI
- Create two workflows
- Trigger the second workflow from the first one, and pass the github event name from the first one to the second with a variable named "firstJobEvent"
Install the nektos/act tool to run your workflows locally.
- Once act is installed, run the command from your cli (
act
) and let it download the docker image it needs. - Create a new repository secret called ACTIONS_STEP_DEBUG and set its value to true
- Re-run your last workflow from the github action UI
- Get a particular line from the job's output and extract a link that points to that line. Save it in a result.
- Download the logs for an entire job
- Create a new repository secret called ACTIONS_RUNNER_DEBUG and set its value to true
- Remove the ACTIONS_STEP_DEBUG secret
- Re-run the last workflow
- Download the logs from the latest job, and compare the two debug mode. What's the major difference ?
- Run your workflow with act. Don't forget to specify the event type.