...
It can generate the versions to change using different base OS versions. That version is specified by ALP_BASE_OS in Makefile.
Limitation
Job execution time - Each job in a workflow can run for up to 6 hours of execution time. If a job reaches this limit, the job is terminated and fails to complete.
Workflow run time - Each workflow run is limited to 72 hours. If a workflow run reaches this limit, the workflow run is cancelled.
API requests - You can execute up to 1000 API requests in an hour across all actions within a repository. If exceeded, additional API calls will fail, which might cause jobs to fail.
Concurrent jobs - The number of concurrent jobs you can run in your account depends on your GitHub plan, as indicated in the following table. If exceeded, any additional jobs are queued.
Architectures
The following processor architectures are supported for the self-hosted runner application.
x64 - Linux, macOS, Windows.
ARM64 - Linux only.
ARM32 - Linux only.
Release cycle - 2 weeks
Semantic versioning uses a structure like <MAJOR>.<MINOR>.<PATCH>
For a new release (i.e., a published version), we increment…
MAJOR when making incompatible API changes,
MINOR when adding backwards-compatible functionality,
PATCH when making backwards-compatible bug fixes.
FAQ
1) If we create a new workflow on master (say, new test), should we add this workflow onto our releases branch or GH do it automatically. Seems, it may also depend on the triggers of such workflow (has it branch-based filter or not).
The order of operations in a workflow run triggered by push or pull request is described in the reference documentation:
The .github/workflows directory in your repository is searched for workflow files at the associated commit SHA or Git ref. The workflow files must be present in that commit SHA or Git ref to be considered.
For example, if the event occurred on a particular repository branch, then the workflow files must be present in the repository on that branch.
2) If we change our workflow on master (change steps inside workflow), will it be updated on another branch we have (say, we add a step to this one). Seems, it may also depend on the triggers of such workflow (has it branch-based filter or not).
We must push changes to the brunch as well.
workflow:
2.1. Create an empty YAML file in the .github/workflows folder or change current
2.2. Create a PR to move that file to your branch
2.3 In your branch, you can now do the necessary edits to get your GH Action up & running. NOTE: next to updating your YAML, you also need to make a change that actually triggers the workflow